summaryrefslogtreecommitdiff
path: root/rfc
diff options
context:
space:
mode:
Diffstat (limited to 'rfc')
-rw-r--r--rfc/README15
-rw-r--r--rfc/README.Reference15
-rw-r--r--rfc/ms-chap.txt1139
-rw-r--r--rfc/pptp-draft.txt3472
-rw-r--r--rfc/rfc1172.txt2312
-rw-r--r--rfc/rfc1332.txt787
-rw-r--r--rfc/rfc1334.txt899
-rw-r--r--rfc/rfc1548.txt2971
-rw-r--r--rfc/rfc1570.txt1057
-rw-r--r--rfc/rfc1661.txt2976
-rw-r--r--rfc/rfc1662.txt1436
-rw-r--r--rfc/rfc1701.txt451
-rw-r--r--rfc/rfc1702.txt227
-rw-r--r--rfc/rfc1877.txt339
-rw-r--r--rfc/rfc1962.txt507
-rw-r--r--rfc/rfc1979.txt563
-rw-r--r--rfc/rfc1990.txt1347
-rw-r--r--rfc/rfc1994.txt732
-rw-r--r--rfc/rfc2138.txt3643
-rw-r--r--rfc/rfc2139.txt1403
-rw-r--r--rfc/rfc2284.txt843
-rw-r--r--rfc/rfc2433.txt1123
-rw-r--r--rfc/rfc2548.txt2299
-rw-r--r--rfc/rfc2637.txt3195
-rw-r--r--rfc/rfc2716.txt1347
-rw-r--r--rfc/rfc2759.txt1123
-rw-r--r--rfc/rfc2865.txt4259
-rw-r--r--rfc/rfc2866.txt1571
-rw-r--r--rfc/rfc2869.txt2635
-rw-r--r--rfc/rfc3078.txt675
-rw-r--r--rfc/rfc3079.txt1179
-rw-r--r--rfc/rfc3544.txt787
-rw-r--r--rfc/rfc3576.txt1683
-rw-r--r--rfc/rfc3580.txt1683
-rw-r--r--rfc/rfc791.txt2887
-rw-r--r--rfc/rfc793.txt5247
36 files changed, 58827 insertions, 0 deletions
diff --git a/rfc/README b/rfc/README
new file mode 100644
index 0000000..a76719b
--- /dev/null
+++ b/rfc/README
@@ -0,0 +1,15 @@
+In this directory are the various standards documents implemented in
+the pptp package.
+
+rfc791.txt Internet Protocol (IP).
+rfc793.txt Transmission Control Protocol (TCP).
+rfc1661.txt The Point-to-Point Protocol (PPP).
+rfc1662.txt PPP in HDLC-like Framing. (serial encoding).
+rfc1701.txt Generic Routing Encapsulation (GRE).
+rfc1702.txt Generic Routing Encapsulation over IPv4 networks.
+rfc1990.txt The PPP Multilink Protocol (MP).
+ms-chap.txt Microsoft PPP CHAP extensions.
+pptp-draft.txt July 1997 draft of the PPTP standard.
+
+rfc1990 is currently unimplemented in pptp
+ CSA, 12/12/97
diff --git a/rfc/README.Reference b/rfc/README.Reference
new file mode 100644
index 0000000..a76719b
--- /dev/null
+++ b/rfc/README.Reference
@@ -0,0 +1,15 @@
+In this directory are the various standards documents implemented in
+the pptp package.
+
+rfc791.txt Internet Protocol (IP).
+rfc793.txt Transmission Control Protocol (TCP).
+rfc1661.txt The Point-to-Point Protocol (PPP).
+rfc1662.txt PPP in HDLC-like Framing. (serial encoding).
+rfc1701.txt Generic Routing Encapsulation (GRE).
+rfc1702.txt Generic Routing Encapsulation over IPv4 networks.
+rfc1990.txt The PPP Multilink Protocol (MP).
+ms-chap.txt Microsoft PPP CHAP extensions.
+pptp-draft.txt July 1997 draft of the PPTP standard.
+
+rfc1990 is currently unimplemented in pptp
+ CSA, 12/12/97
diff --git a/rfc/ms-chap.txt b/rfc/ms-chap.txt
new file mode 100644
index 0000000..f009400
--- /dev/null
+++ b/rfc/ms-chap.txt
@@ -0,0 +1,1139 @@
+
+
+
+
+
+
+Network Working Group S. Cobb
+Informational Memo Microsoft
+Revision 1.3 March 1997
+
+
+ Microsoft PPP CHAP Extensions
+
+
+Status of this Memo
+
+ This document has no official Internet Engineering Task Force
+ status. It is submitted as an example of one vendor's working
+ solution to several authentication issues not yet standardized by
+ the Point-to-Point Working Group.
+
+ The protocol described is implemented in Microsoft Windows NT 3.5
+ and 3.51 and in Microsoft Windows95. Differences between the
+ platforms are noted in the text. This information, plus that in
+ the references, is believed sufficient to implement an
+ interoperating peer.
+
+ 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 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 1334 [2], which the reader should have at hand.
+
+
+History
+
+ Rev 1.21: (Sect 6) Fix error in implicit challenge description
+ Rev 1.22: (Sect 7) Fix error in sub-field table ordering
+ Rev 1.3: (Sect 10) Added hash example section
+
+
+
+
+
+
+
+
+Cobb [Page 1]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+Table Of Contents
+
+ 1. Introduction................................................3
+ 2. LCP Configuration...........................................4
+ 3. Challenge Packet............................................4
+ 4. Response Packet.............................................4
+ 5. Success Packet..............................................8
+ 6. Failure Packet..............................................8
+ 7. Change Password Packet (version 1)..........................9
+ 8. Change Password Packet (version 2).........................12
+ 9. Negotiation Examples.......................................16
+ 10. Hash Example...............................................16
+
+ REFERENCES.....................................................18
+ CHAIR'S ADDRESS................................................19
+ AUTHOR'S ADDRESS...............................................19
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cobb [Page 2]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+1. Introduction
+
+ Microsoft created MS-CHAP to authenticate remote Windows
+ workstations, providing the functionality to which LAN-based users
+ are accustomed.
+
+ The closest fit available in standard PPP is CHAP which is
+ primarily used for mutual secure authentication between WAN-aware
+ routers. Unfortunately, CHAP is not widely used in support of
+ remote workstations where providers commonly require an insecure
+ text login session in place of PPP authentication protocols. To
+ date, several remote workstation issues have not been adequately
+ addressed in CHAP. MS-CHAP addresses these issues and also
+ integrates the encryption and hashing algorithms used on Windows
+ networks.
+
+ Where possible, MS-CHAP is consistent with standard CHAP, and the
+ differences are easily modularized. Microsoft implements MS-CHAP
+ as extensions to it's standard CHAP code base. Briefly,
+ 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 Windows NT 3.5 and 3.51,
+ Microsoft Windows95, and Microsoft LAN Manager 2.x networking
+ products. The MS-CHAP format does not require the
+ authenticator to store a clear or reversibly encrypted
+ password.
+
+ * MS-CHAP provides an authenticator controlled authentication
+ retry mechanism.
+
+ * MS-CHAP provides an authenticator controlled change password
+ mechanism.
+
+ * MS-CHAP defines a set of reason-for-failure codes returned in
+ the Failure packet Message field.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cobb [Page 3]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+2. 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. Non-MS-CHAP-aware implementations
+ that correctly implement LCP Config-Rej have no problem dealing
+ with this non-standard option.
+
+ Microsoft currently negotiates authentication only on the
+ server->workstation configuration. Mutual authentication may be
+ supported in the future.
+
+
+3. 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. It
+ is not necessary for peers to duplicate Microsoft's algorithm for
+ selecting the 8-octet value, but the CHAP guidelines on randomness
+ should be observed.
+
+ Microsoft authenticators do not currently provide information in
+ the Name field. This may change in the future.
+
+
+4. 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 pseudo-code routine LmChallengeResponse below. LAN Manager
+ passwords are limited to 14 case-insensitive OEM characters.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cobb [Page 4]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+ 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 )
+ }
+
+ 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 )
+ }
+
+ DesHash(
+ IN 7-octet Clear,
+ OUT 8-octet Cypher )
+ {
+ Make Cypher an irreversibly encrypted form of Clear by
+ encrypting known text [6] using Clear as the secret key,
+ that is...
+
+ DesEncrypt(
+ StdText,
+ Clear,
+ giving Cypher )
+ }
+
+
+
+
+
+
+
+
+
+
+
+Cobb [Page 5]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+ DesEncrypt(
+ IN 8-octet Clear,
+ IN 7-octet Key,
+ OUT 8-octet Cypher )
+ {
+ Use the DES encryption algorithm [3] 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.
+ }
+
+ 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 )
+ }
+
+
+ The Windows NT compatible challenge response is an encoded
+ function of the password and the received challenge as output by
+ the NtChallengeResponse routine below. The Windows NT password is
+ a string of 0 to (theoretically) 256 case-sensitive Unicode
+ characters. Current versions of Windows NT limit passwords to 14
+ characters, mainly for compatibility reasons, though this may
+ change in the future.
+
+
+
+
+
+
+
+
+
+Cobb [Page 6]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+ 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 )
+ }
+
+ NtPasswordHash(
+ IN 0-to-256-unicode-char Password,
+ OUT 16-octet PasswordHash )
+ {
+ Use the MD4 algorithm [4] to irreversibly hash Password
+ into PasswordHash. Only the password is hashed without
+ including any terminating 0.
+ }
+
+ 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.
+ The LAN Manager response need not be provided (set to 0's) if the
+ implementation expects all user accounts to be stored only in
+ fresh Windows NT account databases or ones where all uploaded
+ passwords have been changed. However, doing so may sacrifice
+ downward compatibility with non-Windows-NT servers.
+
+ If the flag is 0, the Windows NT response is ignored and the LAN
+ Manager response is used. If the password is LAN Manager
+ compatible, interoperability may be achieved without providing the
+ Windows NT challenge response (set to 0's), and providing only the
+ LAN Manager response. This is what Microsoft Windows95 does,
+ though this may change in the future. Doing so may sacrifice
+ interoperability with OEM-specific versions of Windows NT designed
+ for maximum security in Windows-NT-only networks.
+
+ Implementors seeking the broadest possible interoperability are
+ advised to supply both responses when the password is LAN Manager
+ compatible. This is what Microsoft Windows NT does.
+
+
+
+
+
+
+
+Cobb [Page 7]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+ The Name field identifies the authenticatee's user account name.
+ The Windows NT domain name may prefix the user's account name in
+ the typical Windows NT format, e.g. "redmond\stevec" where
+ "redmond" is a Windows NT domain containing the user account
+ "stevec". If a domain is not provided, the backslash should also
+ be omitted, e.g. "stevec".
+
+
+5. Success Packet
+
+ The Success packet is identical in format to the standard CHAP
+ Success packet.
+
+
+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 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 authenticator sets this flag to "1" it disables
+ short timeouts, expecting the authenticatee to prompt the user
+ for new credentials and resubmit the response.
+
+ The "cccccccccccccccc" is 16 hex digits representing an ASCII
+ representation of a new challenge value. This field is
+ optional. If it is not sent, 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. Windows95
+ authenticators may send this field. Windows NT authenticators
+ do not, but may in the future. Both systems implement
+ authenticatee support of this field.
+
+
+
+
+Cobb [Page 8]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+ 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 1.
+
+ Implementations should accept but ignore additional text they do
+ not recognize.
+
+
+7. Change Password Packet (version 1)
+
+ The version 1 Change Password packet does not appear in standard
+ CHAP. It allows the authenticatee 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) in the Message field of the
+ Failure packet.
+
+ This packet type is supported by Windows NT 3.5 and 3.51. It is
+ not supported by Windows95, though this may change in the future.
+ See also Change Password Packet (version 2).
+
+ 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
+
+
+
+
+Cobb [Page 9]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+ 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 an 8-octet key value [6], as
+ output by the pseudo-code routine LmEncryptedPasswordHash
+ below.
+
+ 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 )
+ }
+
+ PasswordHashEncryptedWithBlock(
+ IN 16-octet PasswordHash,
+ IN 7-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,
+ 1st 7-octets Block,
+ giving 2nd 8-octets Cypher )
+ }
+
+
+ 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 an 8-octet key value [6], as
+ output by the pseudo-code routine NtEncryptedPasswordHash
+ below.
+
+
+
+
+
+
+
+
+Cobb [Page 10]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+ 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 )
+ }
+
+
+ Password Length
+
+ The length in octets of the LAN Manager compatible form of the
+ new password. If this value is 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
+
+ Bit field of option flags where 0 is the least significant bit
+ of the 16-bit quantity:
+
+ 0 : Set 1 indicates that the encrypted Windows NT
+ hashed passwords are valid and should be used. If
+ 0, the Windows NT fields are not used and the LAN
+ Manager fields must be provided.
+
+ For the broadest possible interoperability,
+ implementations are encouraged to provide both the
+ Windows NT and LAN Manager fields when the password
+ is LAN Manager compatible. This is what Windows NT
+ does.
+
+ 1-15 : Reserved, always set 0.
+
+
+
+
+
+
+
+
+
+
+
+
+Cobb [Page 11]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+8. Change Password Packet (version 2)
+
+ The version 2 Change Password packet does not appear in standard
+ CHAP. It allows the authenticatee to change the password on the
+ account specified in the previous 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 more in
+ the Message field of the Failure packet.
+
+ This packet type is supported by Windows NT 3.51. It is not
+ supported by Windows NT 3.5 or Windows95, though the latter may
+ change in the future. The version 2 change password packet type
+ is preferable to the version 1 type and should be offered and
+ accepted where possible.
+
+ The format of this packet is as follows:
+
+ 1 octet : Code (=6)
+ 1 octet : Identifier
+ 2 octet : Length (=1070)
+ 516 octets : Password Encrypted with Old NT Hash
+ 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 below:
+
+
+
+Cobb [Page 12]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+ 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 )
+ }
+
+ EncryptPwBlockWithPasswordHash(
+ IN 0-to-256-unicode-char Password,
+ IN 16-octet PasswordHash,
+ OUT datatype-PWBLOCK PwBlock )
+ {
+ Fill ClearPwBlock with random octet values
+ lstrcpyW( to ClearPwBlock.Password, from Password )
+ ClearPwBlock.PasswordLength = lstrlenW( Password )
+
+ Rc4Encrypt(
+ ClearPwBlock,
+ sizeof( ClearPwBlock ),
+ PasswordHash,
+ sizeof( PasswordHash ),
+ giving PwBlock )
+ }
+
+ Rc4Encrypt(
+ IN x-octet Clear,
+ IN integer ClearLength,
+ IN y-octet Key,
+ IN integer KeyLength,
+ OUT x-octet Cypher )
+ {
+ Use the RC4 encryption algorithm [5] 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.
+ }
+
+
+
+
+
+Cobb [Page 13]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+ 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 below:
+
+ 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 )
+
+ PasswordHashEncryptedWithBlock(
+ OldPasswordHash,
+ NewPasswordHash,
+ giving EncrytptedPasswordHash )
+ }
+
+
+ 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 below:
+
+ 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 )
+ }
+
+
+
+
+
+
+
+
+Cobb [Page 14]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+ 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 below:
+
+ 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 )
+
+ PasswordHashEncryptedWithBlock(
+ OldPasswordHash,
+ NewPasswordHash,
+ giving EncrytptedPasswordHash )
+ }
+
+
+ LAN Manager compatible challenge response
+ Windows NT compatible challenge response
+
+ The challenge response fields as described in the Response
+ packet description, but calculated on the new password and the
+ same challenge used in the last response.
+
+
+ Flags
+
+ Bit field of option flags:
+
+ 0 : The "use Windows NT compatible challenge response"
+ flag as described in the Response packet.
+
+ 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. Set 0
+ indicates these fields are not valid.
+
+ For the broadest possible interoperability,
+ implementations are encouraged to provide both the
+ Windows NT and LAN Manager fields when the password
+ is LAN Manager compatible. This is what Windows NT
+ does.
+
+ 2-15 : Reserved, always set 0.
+
+
+Cobb [Page 15]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+9. Negotiation Examples
+
+ Here are some examples of typical negotiations. The authenticatee
+ 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 either 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.
+
+
+ Successful authentication
+
+ <- Challenge
+ Response ->
+ <- Success
+
+
+ Failed authentication with no retry allowed
+
+ <- Challenge
+ Response ->
+ <- Failure (E=691 R=0)
+
+
+ Successful authentication after retry
+
+ <- Challenge
+ Response ->
+ <- Failure (E=691 R=1), disable short timeout
+ Response (++ID) to first challenge+23 ->
+ <- Success
+
+
+ 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 ->
+ <- Failure (E=691 R=0)
+
+
+
+
+
+
+Cobb [Page 16]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+ Successful authentication with password change
+
+ <- Challenge
+ Response ->
+ <- Failure (E=648 R=0), disable short timeout
+ ChangePassword (++ID) to first challenge ->
+ <- Success
+
+ 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), disable short timeout
+ ChangePassword (++ID) to first challenge+23 ->
+ <- Success
+
+
+10. Hash Example
+
+ Intermediate values for password "MyPw".
+
+ 8-octet Challenge:
+ 10 2D B5 DF 08 5D 30 41
+
+ 0-to-14-oem-char LmPassword:
+ 4D 59 50 57
+
+ 16-octet LmPasswordHash:
+ 75 BA 30 19 8E 6D 19 75 AA D3 B4 35 B5 14 04 EE
+
+ 24-octet LmChallengeResponse:
+ 91 88 1D 01 52 AB 0C 33 C5 24 13 5E C2 4A 95 EE
+ 64 E2 3C DC 2D 33 34 7D
+
+ 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
+
+
+
+
+
+
+
+
+
+
+Cobb [Page 17]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+REFERENCES
+
+ [1] Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 1331,
+ Daydreamer, May 1992
+
+ [2] LLoyd, B and Simpson, W., "PPP Authentication Protocols",
+ RFC 1334, L&A and Daydreamer respectively, Octobet 1992
+
+ [3] "Data Encryption Standard (DES)" is Federal Information
+ Processing Standard publication 46, National Institute of
+ Standard and Techology.
+
+ [4] Rivest, R., "MD4 Message Digest Algorithm", RFC 1320, MIT
+ Laboratory for Computer Science and RSA Data Security, Inc.,
+ April 1992.
+
+ [5] RC4 is an encryption standard available from RSA Data Security
+ Inc.
+
+ [6] The 8-octet StdText string used in the LAN Manager compatible
+ password hashing and the 8-octet KeyValue used in the Change
+ Password (version 1) packet are not available for public
+ distribution at this time. Contact the Microsoft Developer
+ Relations group (at time of writing dbeaver@microsoft.com) for
+ details on obtaining these values. On this particular point
+ the author can't help you.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cobb [Page 18]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+CHAIR'S ADDRESS
+
+ The working group can be contacted via the current chair:
+
+ Fred Baker
+ Email: fred@cisco.com
+
+
+
+AUTHOR'S ADDRESS
+
+ The author is a developer in Microsoft's Windows NT
+ Internetworking group, which monitors the ietf-ppp@merit.edu
+ discussions. Questions can also be directed as below, where email
+ is preferred.
+
+ Steve Cobb
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052-6399
+
+ Email: stevec@microsoft.com
+
+ The author maintains an informal mailing list of persons
+ interested in MS-CHAP and other news regarding Windows NT support
+ for PPP authentication protocols. Send email if interested.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cobb [Page 19]
diff --git a/rfc/pptp-draft.txt b/rfc/pptp-draft.txt
new file mode 100644
index 0000000..f58701b
--- /dev/null
+++ b/rfc/pptp-draft.txt
@@ -0,0 +1,3472 @@
+
+Internet Draft Kory Hamzeh
+ Ascend Communications
+ Gurdeep Singh Pall
+ Microsoft Corporation
+ William Verthein
+ U.S. Robotics/3Com
+ Jeff Taarud
+ Copper Mountain Networks
+ W. Andrew Little
+ ECI Telematics
+July 1997
+Expire in six months
+
+
+ Point-to-Point Tunneling Protocol--PPTP
+ draft-ietf-pppext-pptp-02.txt
+
+Status of this Memo
+
+ This document is an Internet-Draft. Internet-Drafts are working
+ documents of the Internet Engineering Task Force (IETF), its areas,
+ and its working groups. Note that other groups may also distribute
+ working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ To learn the current status of any Internet-Draft, please check the
+ "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
+ Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
+ munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
+ ftp.isi.edu (US West Coast).
+
+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
+
+
+
+Hamzeh, et al [Page 1]
+
+Internet Draft PPTP July 1997
+
+
+ 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-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.
+
+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.
+
+ 2) Logical termination of a Point-to-Point-Protocol (PPP) Link
+ Control Protocol (LCP) session.
+
+ 3) Participation in PPP authentication protocols [3].
+
+ 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:
+
+
+
+
+Hamzeh, et al [Page 2]
+
+Internet Draft PPTP July 1997
+
+
+ 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.
+
+ 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 Appendix A.
+
+
+1.2 Terminology
+
+
+Hamzeh, et al [Page 3]
+
+Internet Draft PPTP July 1997
+
+
+ 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.
+
+ 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.
+
+
+
+
+Hamzeh, et al [Page 4]
+
+Internet Draft PPTP July 1997
+
+
+ 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.
+
+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
+
+
+
+Hamzeh, et al [Page 5]
+
+Internet Draft PPTP July 1997
+
+
+ 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. 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 Appendix A of this
+ document.
+
+1.4 Specification Language
+
+ 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",
+
+
+
+Hamzeh, et al [Page 6]
+
+Internet Draft PPTP July 1997
+
+
+ means that, in some circumstances, valid
+ reasons may exist to ignore this item, but the
+ full implications must be understood and
+ carefully weighed before choosing a different
+ course. Unexpected results may result
+ otherwise.
+
+ 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.
+
+ silently discard 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.
+
+
+1.5 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
+
+
+
+Hamzeh, et al [Page 7]
+
+Internet Draft PPTP July 1997
+
+
+ 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.
+
+ 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 3. 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.
+
+
+
+Hamzeh, et al [Page 8]
+
+Internet Draft PPTP July 1997
+
+
+ The MTU for the user data packets encapsulated in GRE is 1532 octets,
+ not including the IP and GRE headers.
+
+2.0 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.
+
+ The TCP header is followed by the PPTP fields shown in the following:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hamzeh, et al [Page 9]
+
+Internet Draft PPTP July 1997
+
+
+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.
+
+ 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.5).
+
+
+
+Hamzeh, et al [Page 10]
+
+Internet Draft PPTP July 1997
+
+
+ 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.
+
+ 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
+
+
+
+Hamzeh, et al [Page 11]
+
+Internet Draft PPTP July 1997
+
+
+ issued by the PNS. If less than 64
+ octets in length, the remainder of this
+ field SHOULD be filled with octets of
+ value 0.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hamzeh, et al [Page 12]
+
+Internet Draft PPTP July 1997
+
+
+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.
+
+ 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
+
+
+
+Hamzeh, et al [Page 13]
+
+Internet Draft PPTP July 1997
+
+
+ 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
+
+ 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.16.
+
+ 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
+
+
+
+Hamzeh, et al [Page 14]
+
+Internet Draft PPTP July 1997
+
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hamzeh, et al [Page 15]
+
+Internet Draft PPTP July 1997
+
+
+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:
+
+ 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.
+
+
+
+Hamzeh, et al [Page 16]
+
+Internet Draft PPTP July 1997
+
+
+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:
+
+ 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.16.
+
+ Reserved1 This field MUST be 0.
+
+
+
+Hamzeh, et al [Page 17]
+
+Internet Draft PPTP July 1997
+
+
+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,
+ 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.
+
+ Identifier A value set by the sender of the Echo-
+ Request that is used to match the reply
+ with the corresponding request.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hamzeh, et al [Page 18]
+
+Internet Draft PPTP July 1997
+
+
+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
+
+ Error Code This field is set to 0 unless a "General
+
+
+
+Hamzeh, et al [Page 19]
+
+Internet Draft PPTP July 1997
+
+
+ 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.16.
+
+ Reserved1 This field MUST be 0.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hamzeh, et al [Page 20]
+
+Internet Draft PPTP July 1997
+
+
+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.
+
+ 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.
+
+
+
+
+Hamzeh, et al [Page 21]
+
+Internet Draft PPTP July 1997
+
+
+ Magic Cookie 0x1A2B3C4D.
+
+ Control Message Type 7 for Outgoing-Call-Request.
+
+ Reserved0 This field MUST be 0.
+
+ 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
+
+
+
+Hamzeh, et al [Page 22]
+
+Internet Draft PPTP July 1997
+
+
+ 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.
+
+ 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 appendix A 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hamzeh, et al [Page 23]
+
+Internet Draft PPTP July 1997
+
+
+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.
+
+ 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.
+
+
+
+
+Hamzeh, et al [Page 24]
+
+Internet Draft PPTP July 1997
+
+
+ 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.
+
+ 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.16.
+
+ 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.
+
+
+
+
+Hamzeh, et al [Page 25]
+
+Internet Draft PPTP July 1997
+
+
+ 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 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 Appendix A
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hamzeh, et al [Page 26]
+
+Internet Draft PPTP July 1997
+
+
+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.
+
+ 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.
+
+
+
+Hamzeh, et al [Page 27]
+
+Internet Draft PPTP July 1997
+
+
+ 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.
+
+ 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.
+
+
+
+Hamzeh, et al [Page 28]
+
+Internet Draft PPTP July 1997
+
+
+ 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 [Page 29]
+
+Internet Draft PPTP July 1997
+
+
+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 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
+
+
+
+Hamzeh, et al [Page 30]
+
+Internet Draft PPTP July 1997
+
+
+ in the Call ID field of the corresponding
+ Incoming-Call-Request message. It is used
+ by 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.16.
+
+ 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. See
+ Appendix A for a description of how this
+ value is determined and used.
+
+ Reserved1 This field MUST be 0.
+
+
+
+
+
+
+
+
+
+
+Hamzeh, et al [Page 31]
+
+Internet Draft PPTP July 1997
+
+
+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
+ 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
+
+
+
+Hamzeh, et al [Page 32]
+
+Internet Draft PPTP July 1997
+
+
+ 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. See
+ Appendix A for a description of how this
+ value is determined and used.
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hamzeh, et al [Page 33]
+
+Internet Draft PPTP July 1997
+
+
+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 [Page 34]
+
+Internet Draft PPTP July 1997
+
+
+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.
+
+ Result Code This value indicates the reason for the
+ disconnect. Current valid Result Code
+
+
+
+Hamzeh, et al [Page 35]
+
+Internet Draft PPTP July 1997
+
+
+ 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.16.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hamzeh, et al [Page 36]
+
+Internet Draft PPTP July 1997
+
+
+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.
+
+ 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.
+
+
+
+Hamzeh, et al [Page 37]
+
+Internet Draft PPTP July 1997
+
+
+ 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.
+
+ Time-out Errors Number of time-outs since call was
+ established.
+
+ Alignment Errors Number of alignment errors since call was
+ established.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hamzeh, et al [Page 38]
+
+Internet Draft PPTP July 1997
+
+
+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.
+
+ 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].
+
+
+
+
+Hamzeh, et al [Page 39]
+
+Internet Draft PPTP July 1997
+
+
+ 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].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hamzeh, et al [Page 40]
+
+Internet Draft PPTP July 1997
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hamzeh, et al [Page 41]
+
+Internet Draft PPTP July 1997
+
+
+3.0 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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hamzeh, et al [Page 42]
+
+Internet Draft PPTP July 1997
+
+
+3.1.1 Control Connection Originator (may be PAC or PNS)
+
+ TCP Open Indication
+ /Send Start Control
+ Connection Request +-----------------+
+ +------------------------------------>| wait_ctl_reply |
+ | +-----------------+
+ | Collision/See (3.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 |
+ +-----------------+
+
+
+
+ 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.
+
+
+
+
+
+
+Hamzeh, et al [Page 43]
+
+Internet Draft PPTP July 1997
+
+
+ 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.
+
+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
+
+
+
+Hamzeh, et al [Page 44]
+
+Internet Draft PPTP July 1997
+
+
+ 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.
+
+ 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.
+
+
+
+
+Hamzeh, et al [Page 45]
+
+Internet Draft PPTP July 1997
+
+
+3.1.3 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.
+
+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
+
+
+
+Hamzeh, et al [Page 46]
+
+Internet Draft PPTP July 1997
+
+
+ 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
+ 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 Outgoing-
+ Call-Reply which also indicates window sizes (see Appendix B). 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.
+
+
+
+
+
+
+
+
+
+Hamzeh, et al [Page 47]
+
+Internet Draft PPTP July 1997
+
+
+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 Accepting
+ | | +------------------------------+ | /Answer call; Send
+ | | | Abort/Send Call | Call Connected
+ ^ V V Disconnect Notify V
+ +-----------------+ +-----------------+
+ | idle |<-----------------------------| established |
+ +-----------------+ Receive Clear Call Request +-----------------+
+ or telco call dropped
+ or local disconnect
+ /Send Call Disconnect Notify
+
+
+
+ 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
+
+
+
+
+Hamzeh, et al [Page 48]
+
+Internet Draft PPTP July 1997
+
+
+ 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
+
+
+
+ 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.
+
+
+
+
+
+Hamzeh, et al [Page 49]
+
+Internet Draft PPTP July 1997
+
+
+ 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 [Page 50]
+
+Internet Draft PPTP July 1997
+
+
+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
+
+
+
+Hamzeh, et al [Page 51]
+
+Internet Draft PPTP July 1997
+
+
+ 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.
+
+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
+
+
+
+Hamzeh, et al [Page 52]
+
+Internet Draft PPTP July 1997
+
+
+ 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.
+
+4.0 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:
+
+
+
+
+
+
+
+
+Hamzeh, et al [Page 53]
+
+Internet Draft PPTP July 1997
+
+
+
+ 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) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ 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
+
+
+
+Hamzeh, et al [Page 54]
+
+Internet Draft PPTP July 1997
+
+
+ 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).
+
+ 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.
+
+
+
+
+
+
+
+Hamzeh, et al [Page 55]
+
+Internet Draft PPTP July 1997
+
+
+4.3 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.4 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.
+
+ 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.
+
+5.0 Security Considerations
+
+ Security issues are not addressed in this document. End to end
+ security is addressed by PPP. Further security considerations will be
+ addressed by the next version of PPTP.
+
+
+
+
+
+
+
+Hamzeh, et al [Page 56]
+
+Internet Draft PPTP July 1997
+
+
+6.0 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
+
+7.0 References
+
+ [1] Hanks, S. Li, T., Farinacci, D. Traina, P., "Generic Routing
+ Encapsulation (GRE)", RFC 1701, October 1994.
+
+ [2] Hanks, S. Li, T., Farinacci, D. Traina, P., "Generic Routing
+ Encapsulation (GRE) over IPv4 Networks", RFC 1702, October 1994.
+
+ [3] Lloyd, B. Simpson, W., "PPP Authentication Protocols", RFC 1334,
+ October 1992.
+
+ [4] Postel, J. B., "Transmission Control Protocol", RFC 791,
+ September 1981
+
+ [5] Postel, J. B., "User Data Protocol", RFC 768, August 1980.
+
+ [6] Reynolds, J., Postel, J., "Assigned Numbers", RFC 1700, October,
+ 1994.
+
+ [7] Simpson, W., editor, "The Point-to-Point Protocol (PPP)", RFC
+ 1661, July 1994.
+
+ [8] Ethertype for PPP, Reserved with Xerox Corporation.
+
+
+
+
+
+Hamzeh, et al [Page 57]
+
+Internet Draft PPTP July 1997
+
+
+Appendix A. 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.
+
+ 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
+
+
+
+Hamzeh, et al [Page 58]
+
+Internet Draft PPTP July 1997
+
+
+ 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.
+
+
+Packet Processing Delay (PPD)
+
+ The 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.
+
+ The value of PPD is used to seed the adaptive algorithm with the
+ initial RTT[n-1] value.
+
+Sample
+
+ Sample is the actual measured time for a returned acknowledgment.
+
+Round-Trip Time (RTT)
+
+ The RTT value represents an estimate of the average time it takes for
+ an acknowledgment to be received after a packet is sent to the remote
+
+
+
+Hamzeh, et al [Page 59]
+
+Internet Draft PPTP July 1997
+
+
+ end of the tunnel.
+
+
+A.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 Richard Steven's book TCP/IP
+ Illustrated, Volume 1 (page 300). '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] = 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
+ calculated 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.
+
+ 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
+
+
+
+Hamzeh, et al [Page 60]
+
+Internet Draft PPTP July 1997
+
+
+ division.
+
+
+A.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. A simple formula called
+ Karn's Algorithm is used in TCP implementations and may be used in
+ implementing the backoff timers for the PNS or the PAC. Notice that
+ in addition to increasing the time-out, we are also shrinking the
+ size of the window as described in the next section.
+
+ Karn's timer backoff algorithm, as used in TCP, is:
+
+
+ NewTIMEOUT = delta * TIMEOUT
+
+ Adapted to our time-out calculations, 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] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut)
+
+ In this modified calculation of ATO, only the two values that
+ contribute to ATO and that are stored for the next iteration are
+ calculated. RTT is scaled by chi, 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.
+
+Appendix B. Acknowledgment Time-Out and Window Adjustment
+
+B.1 Initial Window Size
+
+ Although each side has indicated the maximum size of its receive
+ window, it is recommended that a slow start method be used to begin
+ transmitting 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
+
+
+
+Hamzeh, et al [Page 61]
+
+Internet Draft PPTP July 1997
+
+
+ congested network because no history has been established.
+
+B.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.
+
+B.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.
+
+B.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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hamzeh, et al [Page 62]
+
+
diff --git a/rfc/rfc1172.txt b/rfc/rfc1172.txt
new file mode 100644
index 0000000..5307640
--- /dev/null
+++ b/rfc/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/rfc/rfc1332.txt b/rfc/rfc1332.txt
new file mode 100644
index 0000000..3e12042
--- /dev/null
+++ b/rfc/rfc1332.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group G. McGregor
+Request for Comments: 1332 Merit
+Obsoletes: RFC 1172 May 1992
+
+
+
+ The PPP Internet Protocol Control Protocol (IPCP)
+
+
+
+Status of this Memo
+
+ This RFC specifies an IAB standards track protocol for the Internet
+ community, and requests discussion and suggestions for improvements.
+ Please refer to the current edition of the "IAB Official Protocol
+ Standards" for the standardization state and status of this protocol.
+ Distribution of this memo is unlimited.
+
+Abstract
+
+ The Point-to-Point Protocol (PPP) [1] provides a standard method of
+ encapsulating Network Layer protocol information over point-to-point
+ links. PPP also defines an extensible Link Control Protocol, and
+ proposes a family of Network Control Protocols (NCPs) for
+ establishing and configuring different network-layer protocols.
+
+ This document defines the NCP for establishing and configuring the
+ Internet Protocol [2] over PPP, and a method to negotiate and use Van
+ Jacobson TCP/IP header compression [3] with PPP.
+
+ This RFC is a product of the Point-to-Point Protocol Working Group of
+ the Internet Engineering Task Force (IETF).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McGregor [Page i]
+
+RFC 1332 PPP IPCP May 1992
+
+
+Table of Contents
+
+
+ 1. Introduction .......................................... 1
+
+ 2. A PPP Network Control Protocol (NCP) for IP ........... 2
+ 2.1 Sending IP Datagrams ............................ 2
+
+ 3. IPCP Configuration Options ............................ 4
+ 3.1 IP-Addresses .................................... 5
+ 3.2 IP-Compression-Protocol ......................... 6
+ 3.3 IP-Address ...................................... 8
+
+ 4. Van Jacobson TCP/IP header compression ................ 9
+ 4.1 Configuration Option Format ..................... 9
+
+ APPENDICES ................................................... 11
+
+ A. IPCP Recommended Options .............................. 11
+
+ SECURITY CONSIDERATIONS ...................................... 11
+
+ REFERENCES ................................................... 11
+
+ ACKNOWLEDGEMENTS ............................................. 11
+
+ CHAIR'S ADDRESS .............................................. 12
+
+ AUTHOR'S ADDRESS ............................................. 12
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McGregor [Page ii]
+
+RFC 1332 PPP IPCP May 1992
+
+
+1. Introduction
+
+ PPP has three main components:
+
+ 1. A method for encapsulating datagrams over serial links.
+
+ 2. A Link Control Protocol (LCP) for establishing, configuring,
+ and testing the data-link connection.
+
+ 3. A family of Network Control Protocols (NCPs) for establishing
+ and configuring different network-layer protocols.
+
+ In order to establish communications over a point-to-point link, each
+ end of the PPP link must first send LCP packets to configure and test
+ the data link. After the link has been established and optional
+ facilities have been negotiated as needed by the LCP, PPP must send
+ NCP packets to choose and configure one or more network-layer
+ protocols. Once each of the chosen network-layer protocols has been
+ configured, datagrams from each network-layer protocol can be sent
+ over the link.
+
+ The link will remain configured for communications until explicit LCP
+ or NCP packets close the link down, or until some external event
+ occurs (an inactivity timer expires or network administrator
+ intervention).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McGregor [Page 1]
+
+RFC 1332 PPP IPCP May 1992
+
+
+2. A PPP Network Control Protocol (NCP) for IP
+
+ The IP Control Protocol (IPCP) is responsible for configuring,
+ enabling, and disabling the IP protocol modules on both ends of the
+ point-to-point link. IPCP uses the same packet exchange machanism as
+ the Link Control Protocol (LCP). IPCP packets may not be exchanged
+ until PPP has reached the Network-Layer Protocol phase. IPCP packets
+ received before this phase is reached should be silently discarded.
+
+ The IP Control Protocol is exactly the same as the Link Control
+ Protocol [1] with the following exceptions:
+
+ Data Link Layer Protocol Field
+
+ Exactly one IPCP packet is encapsulated in the Information field
+ of PPP Data Link Layer frames where the Protocol field indicates
+ type hex 8021 (IP Control Protocol).
+
+ Code field
+
+ Only Codes 1 through 7 (Configure-Request, Configure-Ack,
+ Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack
+ and Code-Reject) are used. Other Codes should be treated as
+ unrecognized and should result in Code-Rejects.
+
+ Timeouts
+
+ IPCP packets may not be exchanged until PPP has reached the
+ Network-Layer Protocol phase. An implementation should be
+ prepared to wait for Authentication and Link Quality Determination
+ to finish before timing out waiting for a Configure-Ack or other
+ response. It is suggested that an implementation give up only
+ after user intervention or a configurable amount of time.
+
+ Configuration Option Types
+
+ IPCP has a distinct set of Configuration Options, which are
+ defined below.
+
+2.1. Sending IP Datagrams
+
+ Before any IP packets may be communicated, PPP must reach the
+ Network-Layer Protocol phase, and the IP Control Protocol must reach
+ the Opened state.
+
+ Exactly one IP packet is encapsulated in the Information field of PPP
+ Data Link Layer frames where the Protocol field indicates type hex
+ 0021 (Internet Protocol).
+
+
+
+McGregor [Page 2]
+
+RFC 1332 PPP IPCP May 1992
+
+
+ The maximum length of an IP packet transmitted over a PPP link is the
+ same as the maximum length of the Information field of a PPP data
+ link layer frame. Larger IP datagrams must be fragmented as
+ necessary. If a system wishes to avoid fragmentation and reassembly,
+ it should use the TCP Maximum Segment Size option [4], and MTU
+ discovery [5].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McGregor [Page 3]
+
+RFC 1332 PPP IPCP May 1992
+
+
+3. IPCP Configuration Options
+
+IPCP Configuration Options allow negotiatiation of desirable Internet
+Protocol parameters. IPCP uses the same Configuration Option format
+defined for LCP [1], with a separate set of Options.
+
+The most up-to-date values of the IPCP Option Type field are specified
+in the most recent "Assigned Numbers" RFC [6]. Current values are
+assigned as follows:
+
+ 1 IP-Addresses
+ 2 IP-Compression-Protocol
+ 3 IP-Address
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McGregor [Page 4]
+
+RFC 1332 PPP IPCP May 1992
+
+
+3.1. IP-Addresses
+
+ Description
+
+ The use of the Configuration Option IP-Addresses has been
+ deprecated. It has been determined through implementation
+ experience that it is difficult to ensure negotiation convergence
+ in all cases using this option. RFC 1172 [7] provides information
+ for implementations requiring backwards compatability. The IP-
+ Address Configuration Option replaces this option, and its use is
+ preferred.
+
+ This option SHOULD NOT be sent in a Configure-Request if a
+ Configure-Request has been received which includes either an IP-
+ Addresses or IP-Address option. This option MAY be sent if a
+ Configure-Reject is received for the IP-Address option, or a
+ Configure-Nak is received with an IP-Addresses option as an
+ appended option.
+
+ Support for this option MAY be removed after the IPCP protocol
+ status advances to Internet Draft Standard.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McGregor [Page 5]
+
+RFC 1332 PPP IPCP May 1992
+
+
+3.2. IP-Compression-Protocol
+
+ Description
+
+ This Configuration Option provides a way to negotiate the use of a
+ specific compression protocol. By default, compression is not
+ enabled.
+
+ A summary of the IP-Compression-Protocol Configuration Option format
+ is shown below. The fields are transmitted from left to right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | IP-Compression-Protocol |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Data ...
+ +-+-+-+-+
+
+ Type
+
+ 2
+
+ Length
+
+ >= 4
+
+ IP-Compression-Protocol
+
+ The IP-Compression-Protocol field is two octets and indicates the
+ compression protocol desired. Values for this field are always
+ the same as the PPP Data Link Layer Protocol field values for that
+ same compression protocol.
+
+ The most up-to-date values of the IP-Compression-Protocol field
+ are specified in the most recent "Assigned Numbers" RFC [6].
+ Current values are assigned as follows:
+
+ Value (in hex) Protocol
+
+ 002d Van Jacobson Compressed TCP/IP
+
+ Data
+
+ The Data field is zero or more octets and contains additional data
+ as determined by the particular compression protocol.
+
+
+
+
+
+McGregor [Page 6]
+
+RFC 1332 PPP IPCP May 1992
+
+
+ Default
+
+ No compression protocol enabled.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McGregor [Page 7]
+
+RFC 1332 PPP IPCP May 1992
+
+
+3.3. IP-Address
+
+ Description
+
+ This Configuration Option provides a way to negotiate the IP
+ address to be used on the local end of the link. It allows the
+ sender of the Configure-Request to state which IP-address is
+ desired, or to request that the peer provide the information. The
+ peer can provide this information by NAKing the option, and
+ returning a valid IP-address.
+
+ If negotiation about the remote IP-address is required, and the
+ peer did not provide the option in its Configure-Request, the
+ option SHOULD be appended to a Configure-Nak. The value of the
+ IP-address given must be acceptable as the remote IP-address, or
+ indicate a request that the peer provide the information.
+
+ By default, no IP address is assigned.
+
+ A summary of the IP-Address Configuration Option format is shown
+ below. The fields are transmitted from left to right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | IP-Address
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ IP-Address (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 3
+
+ Length
+
+ 6
+
+ IP-Address
+
+ The four octet IP-Address is the desired local address of the
+ sender of a Configure-Request. If all four octets are set to
+ zero, it indicates a request that the peer provide the IP-Address
+ information.
+
+ Default
+
+ No IP address is assigned.
+
+
+
+McGregor [Page 8]
+
+RFC 1332 PPP IPCP May 1992
+
+
+4. Van Jacobson TCP/IP header compression
+
+Van Jacobson TCP/IP header compression reduces the size of the TCP/IP
+headers to as few as three bytes. This can be a significant improvement
+on slow serial lines, particularly for interactive traffic.
+
+The IP-Compression-Protocol Configuration Option is used to indicate the
+ability to receive compressed packets. Each end of the link must
+separately request this option if bi-directional compression is desired.
+
+The PPP Protocol field is set to the following values when transmitting
+IP packets:
+
+ Value (in hex)
+
+ 0021 Type IP. The IP protocol is not TCP, or the packet is a
+ fragment, or cannot be compressed.
+
+ 002d Compressed TCP. The TCP/IP headers are replaced by the
+ compressed header.
+
+ 002f Uncompressed TCP. The IP protocol field is replaced by
+ the slot identifier.
+
+4.1. Configuration Option Format
+
+ A summary of the IP-Compression-Protocol Configuration Option format
+ to negotiate Van Jacobson TCP/IP header compression is shown below.
+ The fields are transmitted from left to right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | IP-Compression-Protocol |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Max-Slot-Id | Comp-Slot-Id |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 2
+
+ Length
+
+ 6
+
+
+
+
+
+
+McGregor [Page 9]
+
+RFC 1332 PPP IPCP May 1992
+
+
+ IP-Compression-Protocol
+
+ 002d (hex) for Van Jacobson Compressed TCP/IP headers.
+
+ Max-Slot-Id
+
+ The Max-Slot-Id field is one octet and indicates the maximum slot
+ identifier. This is one less than the actual number of slots; the
+ slot identifier has values from zero to Max-Slot-Id.
+
+ Note: There may be implementations that have problems with only
+ one slot (Max-Slot-Id = 0). See the discussion in reference
+ [3]. The example implementation in [3] will only work with 3
+ through 254 slots.
+
+ Comp-Slot-Id
+
+ The Comp-Slot-Id field is one octet and indicates whether the slot
+ identifier field may be compressed.
+
+ 0 The slot identifier must not be compressed. All compressed
+ TCP packets must set the C bit in every change mask, and
+ must include the slot identifier.
+
+ 1 The slot identifer may be compressed.
+
+ The slot identifier must not be compressed if there is no ability
+ for the PPP link level to indicate an error in reception to the
+ decompression module. Synchronization after errors depends on
+ receiving a packet with the slot identifier. See the discussion
+ in reference [3].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McGregor [Page 10]
+
+RFC 1332 PPP IPCP May 1992
+
+
+A. IPCP Recommended Options
+
+ The following Configurations Options are recommended:
+
+ IP-Compression-Protocol -- with at least 4 slots, usually 16
+ slots.
+
+ IP-Address -- only on dial-up lines.
+
+
+Security Considerations
+
+ Security issues are not discussed in this memo.
+
+
+References
+
+ [1] Simpson, W., "The Point-to-Point Protocol", RFC 1331, May 1992.
+
+ [2] Postel, J., "Internet Protocol", RFC 791, USC/Information
+ Sciences Institute, September 1981.
+
+ [3] Jacobson, V., "Compressing TCP/IP Headers", RFC 1144, January
+ 1990.
+
+ [4] Postel, J., "The TCP Maximum Segment Size Option and Related
+ Topics", RFC 879, USC/Information Sciences Institute, November
+ 1983.
+
+ [5] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
+ November 1990.
+
+ [6] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060,
+ USC/Information Sciences Institute, March 1990.
+
+ [7] Perkins, D., and R. Hobby, "Point-to-Point Protocol (PPP)
+ initial configuration options", RFC 1172, August 1990.
+
+
+Acknowledgments
+
+ Some of the text in this document is taken from RFCs 1171 & 1172, by
+ Drew Perkins of Carnegie Mellon University, and by Russ Hobby of the
+ University of California at Davis.
+
+ Information leading to the expanded IP-Compression option provided by
+ Van Jacobson at SIGCOMM '90.
+
+
+
+
+McGregor [Page 11]
+
+RFC 1332 PPP IPCP May 1992
+
+
+ Bill Simpson helped with the document formatting.
+
+
+Chair's Address
+
+ The working group can be contacted via the current chair:
+
+ Brian Lloyd
+ Lloyd & Associates
+ 3420 Sudbury Road
+ Cameron Park, California 95682
+
+ Phone: (916) 676-1147
+
+ EMail: brian@ray.lloyd.com
+
+
+
+Author's Address
+
+ Questions about this memo can also be directed to:
+
+ Glenn McGregor
+ Merit Network, Inc.
+ 1071 Beal Avenue
+ Ann Arbor, MI 48109-2103
+
+ Phone: (313) 763-1203
+
+ EMail: Glenn.McGregor@Merit.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McGregor [Page 12]
+
diff --git a/rfc/rfc1334.txt b/rfc/rfc1334.txt
new file mode 100644
index 0000000..6051f48
--- /dev/null
+++ b/rfc/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/rfc/rfc1548.txt b/rfc/rfc1548.txt
new file mode 100644
index 0000000..7b8a33a
--- /dev/null
+++ b/rfc/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/rfc/rfc1570.txt b/rfc/rfc1570.txt
new file mode 100644
index 0000000..edda5d9
--- /dev/null
+++ b/rfc/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/rfc/rfc1661.txt b/rfc/rfc1661.txt
new file mode 100644
index 0000000..02112bd
--- /dev/null
+++ b/rfc/rfc1661.txt
@@ -0,0 +1,2976 @@
+
+
+
+
+
+
+Network Working Group W. Simpson, Editor
+Request for Comments: 1661 Daydreamer
+STD: 51 July 1994
+Obsoletes: 1548
+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.
+
+
+Table of Contents
+
+
+ 1. Introduction .......................................... 1
+ 1.1 Specification of Requirements ................... 2
+ 1.2 Terminology ..................................... 3
+
+ 2. PPP Encapsulation ..................................... 4
+
+
+Simpson [Page i]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+ 3. PPP Link Operation .................................... 6
+ 3.1 Overview ........................................ 6
+ 3.2 Phase Diagram ................................... 6
+ 3.3 Link Dead (physical-layer not ready) ............ 7
+ 3.4 Link Establishment Phase ........................ 7
+ 3.5 Authentication Phase ............................ 8
+ 3.6 Network-Layer Protocol Phase .................... 8
+ 3.7 Link Termination Phase .......................... 9
+
+ 4. The Option Negotiation Automaton ...................... 11
+ 4.1 State Transition Table .......................... 12
+ 4.2 States .......................................... 14
+ 4.3 Events .......................................... 16
+ 4.4 Actions ......................................... 21
+ 4.5 Loop Avoidance .................................. 23
+ 4.6 Counters and Timers ............................. 24
+
+ 5. LCP Packet Formats .................................... 26
+ 5.1 Configure-Request ............................... 28
+ 5.2 Configure-Ack ................................... 29
+ 5.3 Configure-Nak ................................... 30
+ 5.4 Configure-Reject ................................ 31
+ 5.5 Terminate-Request and Terminate-Ack ............. 33
+ 5.6 Code-Reject ..................................... 34
+ 5.7 Protocol-Reject ................................. 35
+ 5.8 Echo-Request and Echo-Reply ..................... 36
+ 5.9 Discard-Request ................................. 37
+
+ 6. LCP Configuration Options ............................. 39
+ 6.1 Maximum-Receive-Unit (MRU) ...................... 41
+ 6.2 Authentication-Protocol ......................... 42
+ 6.3 Quality-Protocol ................................ 43
+ 6.4 Magic-Number .................................... 45
+ 6.5 Protocol-Field-Compression (PFC) ................ 48
+ 6.6 Address-and-Control-Field-Compression (ACFC)
+
+ SECURITY CONSIDERATIONS ...................................... 51
+ REFERENCES ................................................... 51
+ ACKNOWLEDGEMENTS ............................................. 51
+ CHAIR'S ADDRESS .............................................. 52
+ EDITOR'S ADDRESS ............................................. 52
+
+
+
+
+
+
+
+
+
+
+Simpson [Page ii]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+1. Introduction
+
+ The Point-to-Point Protocol is designed for simple links which
+ transport packets between two peers. These links provide full-duplex
+ simultaneous bi-directional operation, and are assumed to deliver
+ packets in order. It is intended that PPP provide a common solution
+ for easy connection of a wide variety of hosts, bridges and routers
+ [1].
+
+ Encapsulation
+
+ The PPP encapsulation provides for multiplexing of different
+ network-layer protocols simultaneously over the same link. 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 within the default HDLC-like 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, detect a looped-back link and other common
+ misconfiguration errors, and terminate the link. Other optional
+ facilities provided are authentication of the identity of its peer
+ on the link, and determination when a link is functioning properly
+ and when it is failing.
+
+ 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
+
+
+
+Simpson [Page 1]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+ respective network-layer protocols. These NCPs are defined in
+ companion documents.
+
+ 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 2]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+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
+ The implementation discards the packet without further
+ processing. The implementation SHOULD provide the
+ capability of logging the error, including the contents of
+ the silently discarded packet, and SHOULD record the event
+ in a statistics counter.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 3]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+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.
+
+ A summary of the PPP encapsulation is shown below. The fields are
+ transmitted from left to right.
+
+ +----------+-------------+---------+
+ | Protocol | Information | Padding |
+ | 8/16 bits| * | * |
+ +----------+-------------+---------+
+
+
+ Protocol Field
+
+ The Protocol field is one or 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).
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 4]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+ Up-to-date values of the Protocol field are specified in the most
+ recent "Assigned Numbers" RFC [2]. This specification reserves
+ the following values:
+
+ Value (in hex) Protocol Name
+
+ 0001 Padding Protocol
+ 0003 to 001f reserved (transparency inefficient)
+ 007d reserved (Control Escape)
+ 00cf reserved (PPP NLPID)
+ 00ff reserved (compression inefficient)
+
+ 8001 to 801f unused
+ 807d unused
+ 80cf unused
+ 80ff unused
+
+ 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.
+
+ The maximum length for the Information field, including Padding,
+ but not including the Protocol field, 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.
+
+
+
+
+
+
+Simpson [Page 5]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+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 which are specified in the following simplified state diagram:
+
+ +------+ +-----------+ +--------------+
+ | | UP | | OPENED | | SUCCESS/NONE
+ | Dead |------->| Establish |---------->| Authenticate |--+
+ | | | | | | |
+ +------+ +-----------+ +--------------+ |
+ ^ | | |
+ | FAIL | FAIL | |
+ +<--------------+ +----------+ |
+ | | |
+ | +-----------+ | +---------+ |
+ | DOWN | | | CLOSING | | |
+ +------------| Terminate |<---+<----------| Network |<-+
+ | | | |
+ +-----------+ +---------+
+
+ Not all transitions are specified in this diagram. The following
+ semantics MUST be followed.
+
+
+
+
+
+
+
+Simpson [Page 6]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+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 later) will be in the
+ Initial or Starting states. The transition to the Link Establishment
+ phase will signal an Up event to the LCP 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 link,
+ 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 later) has been both sent and received.
+
+ All Configuration Options are assumed to be at default values unless
+ altered by the configuration exchange. See the chapter 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.
+
+ The receipt of the LCP Configure-Request causes a return to the Link
+ Establishment phase from the Network-Layer Protocol phase or
+ Authentication phase.
+
+
+
+
+
+
+
+
+Simpson [Page 7]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+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 request the use of that authentication
+ protocol during Link Establishment phase.
+
+ 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. If
+ authentication fails, the authenticator SHOULD proceed instead to the
+ Link Termination phase.
+
+ Only Link Control Protocol, authentication protocol, and link quality
+ monitoring packets are allowed during this phase. All other packets
+ received during this phase MUST be silently discarded.
+
+ Implementation Notes:
+
+ An implementation SHOULD NOT fail authentication simply due to
+ timeout or lack of response. The authentication SHOULD allow some
+ method of retransmission, and proceed to the Link Termination
+ phase only after a number of authentication attempts has been
+ exceeded.
+
+ The implementation responsible for commencing Link Termination
+ phase is the implementation which has refused authentication to
+ its peer.
+
+
+
+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.
+
+
+
+
+
+Simpson [Page 8]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+ 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 supported
+ network-layer protocol packets received when the corresponding NCP is
+ not in the Opened state MUST be silently discarded.
+
+ Implementation Note:
+
+ While LCP is in the Opened state, any protocol packet which is
+ unsupported by the implementation MUST be returned in a Protocol-
+ Reject (described later). 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
+ 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.
+
+
+
+
+Simpson [Page 9]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 10]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+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
+
+ TO+ = Timeout with counter > 0 irc = Initialize-Restart-Count
+ TO- = Timeout with counter expired zrc = Zero-Restart-Count
+
+ RCR+ = Receive-Configure-Request (Good) scr = Send-Configure-Request
+ RCR- = Receive-Configure-Request (Bad)
+ RCA = Receive-Configure-Ack sca = Send-Configure-Ack
+ RCN = Receive-Configure-Nak/Rej scn = Send-Configure-Nak/Rej
+
+ RTR = Receive-Terminate-Request str = Send-Terminate-Request
+ RTA = Receive-Terminate-Ack sta = Send-Terminate-Ack
+
+ RUC = Receive-Unknown-Code scj = Send-Code-Reject
+ RXJ+ = 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
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 11]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+4.1. 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 tlf/0 2 2 4 4
+ |
+ TO+ | - - - - str/4 str/5
+ TO- | - - - - tlf/2 tlf/3
+ |
+ RCR+ | - - sta/2 irc,scr,sca/8 4 5
+ RCR- | - - sta/2 irc,scr,scn/6 4 5
+ RCA | - - sta/2 sta/3 4 5
+ RCN | - - sta/2 sta/3 4 5
+ |
+ RTR | - - sta/2 sta/3 sta/4 sta/5
+ RTA | - - 2 3 tlf/2 tlf/3
+ |
+ RUC | - - scj/2 scj/3 scj/4 scj/5
+ RXJ+ | - - 2 3 4 5
+ RXJ- | - - tlf/2 tlf/3 tlf/2 tlf/3
+ |
+ RXR | - - 2 3 4 5
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 12]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+
+ | 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-Count 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.
+
+ The events and actions are defined according to a message passing
+ architecture, rather than a signalling architecture. If an action is
+ desired to control specific signals (such as DTR), additional actions
+ are likely to be required.
+
+ [p] Passive option; see Stopped state discussion.
+
+ [r] Restart option; see Open event discussion.
+
+ [x] Crossed connection; see RCA event discussion.
+
+
+
+
+
+
+Simpson [Page 13]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+4.2. 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.
+
+ 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
+
+
+
+Simpson [Page 14]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+ 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.
+
+ 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, the Closed state is
+ 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
+
+
+
+Simpson [Page 15]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+ 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 running, since a Configure-Ack has
+ not yet been received.
+
+ Opened
+
+ In the Opened state, a Configure-Ack has been both sent and
+ received. The Restart timer is not running.
+
+ 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.3. Events
+
+ Transitions and actions in the automaton are caused by events.
+
+ Up
+
+ This 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
+
+ This event occurs when a lower layer indicates that it is no
+
+
+
+Simpson [Page 16]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+ 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
+
+ This 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.
+
+ 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. Care must be taken that an intervening Down event
+ cannot occur from another source.
+
+ The Down followed by an Up will cause an orderly renegotiation
+ of the link, by progressing through the Starting to the
+ Request-Sent state. This will cause the renegotiation of the
+ link, without any harmful side effects.
+
+ Close
+
+ This event indicates that the link is not available for traffic;
+
+
+
+Simpson [Page 17]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+ 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. Care
+ must be taken that an intervening Close event cannot occur from
+ another source.
+
+ The Close followed by an Open will cause an orderly termination
+ of the link, by progressing through 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-
+ 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
+
+
+
+Simpson [Page 18]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+ 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)
+
+ This 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.
+
+ 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)
+
+ This event occurs when a Terminate-Request packet is received.
+ The Terminate-Request packet indicates the desire of the peer to
+
+
+
+Simpson [Page 19]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+ 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)
+
+ This 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)
+
+ This 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
+ 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 an Echo-Request packet. There is no reply to an
+ Echo-Reply or Discard-Request packet.
+
+
+
+
+
+
+Simpson [Page 20]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+4.4. 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
+ 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.
+
+ This results of this action are highly implementation dependent.
+
+ This-Layer-Finished (tlf)
+
+ This action indicates to the lower layers that the automaton is
+ entering the Initial, Closed or Stopped 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.
+
+
+
+Simpson [Page 21]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+ 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.
+
+ This results of this action are highly implementation dependent.
+
+ Initialize-Restart-Count (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.
+
+ 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-Count (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)
+
+ A Configure-Request packet is transmitted. 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)
+
+ A Configure-Ack packet is transmitted. This acknowledges the
+ reception of a Configure-Request packet with an acceptable set of
+ Configuration Options.
+
+ Send-Configure-Nak (scn)
+
+ A Configure-Nak or Configure-Reject packet is transmitted, as
+ appropriate. This negative response reports the reception of a
+
+
+
+Simpson [Page 22]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+ 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 chapter on LCP Packet Formats.
+
+ Send-Terminate-Request (str)
+
+ A Terminate-Request packet is transmitted. 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)
+
+ A Terminate-Ack packet is transmitted. This acknowledges the
+ reception of a Terminate-Request packet or otherwise serves to
+ synchronize the automatons.
+
+ Send-Code-Reject (scj)
+
+ A Code-Reject packet is transmitted. This indicates the reception
+ of an unknown type of packet.
+
+ Send-Echo-Reply (ser)
+
+ An Echo-Reply packet is transmitted. This acknowledges the
+ reception of an Echo-Request packet.
+
+
+
+4.5. 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.
+
+
+
+
+
+Simpson [Page 23]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+4.6. 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 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.
+
+
+
+
+Simpson [Page 24]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+ 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 for peer requested
+ options are converted to Configure-Reject packets, and locally
+ desired options are no longer appended. Max-Failure MUST be
+ configurable, but SHOULD default to five (5) transmissions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 25]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+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
+ 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).
+
+ In the interest of simplicity, there is no version field in the LCP
+ packet. A correctly functioning LCP implementation will always
+ respond to unknown Protocols and Codes with an easily recognizable
+ LCP 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
+ negotiated. In particular, each Configuration Option specifies a
+ default value. This ensures that such LCP packets are always
+ recognizable, even when one end of the link mistakenly believes the
+ link to be open.
+
+ 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 ...
+ +-+-+-+-+
+
+
+ Code
+
+ The Code field is one octet, and identifies the kind of LCP
+
+
+
+Simpson [Page 26]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+ packet. When a packet is received with an unknown 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 document 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 without affecting the
+ automaton.
+
+ Length
+
+ The Length field is two octets, and indicates the length of the
+ LCP packet, including the Code, Identifier, Length and Data
+ fields. The Length MUST NOT exceed the MRU of the link.
+
+ 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
+ without affecting the automaton.
+
+ 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.
+
+
+
+
+
+
+
+
+Simpson [Page 27]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+5.1. Configure-Request
+
+ Description
+
+ An implementation wishing to open a connection MUST transmit a
+ Configure-Request. The Options field is 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 contents 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 chapter.
+
+
+
+
+
+
+
+
+
+Simpson [Page 28]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+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 Configure-Ack. The acknowledged
+ Configuration Options MUST NOT be reordered or modified in any
+ way.
+
+ 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.
+
+
+
+
+
+
+
+
+Simpson [Page 29]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+5.3. Configure-Nak
+
+ Description
+
+ If every instance of the received Configuration Options is
+ recognizable, but some values are not acceptable, then the
+ implementation MUST transmit a Configure-Nak. The Options field
+ is 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
+ 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 when a new
+ Configure-Request is sent, the Configuration Options MAY be
+ 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
+
+
+
+Simpson [Page 30]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+ 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 ...
+ +-+-+-+-+
+
+
+ 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 Configure-Reject. The Options field is 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
+
+
+
+Simpson [Page 31]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+ 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 when a new
+ Configure-Request is sent, it MUST 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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 32]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+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.
+
+ An implementation wishing to close a connection SHOULD transmit a
+ Terminate-Request. 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 Terminate-Ack MUST be
+ transmitted.
+
+ 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
+ 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.
+
+
+
+
+Simpson [Page 33]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+ 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. The end of the field is indicated by the Length.
+
+
+
+5.6. Code-Reject
+
+ Description
+
+ Reception of a LCP packet with an unknown Code indicates that the
+ peer is operating with a different version. This MUST be reported
+ back to the sender of the unknown Code by transmitting a Code-
+ Reject.
+
+ Upon reception of the Code-Reject of a code which is fundamental
+ to this version of the protocol, the implementation SHOULD report
+ the problem and drop the connection, since it is unlikely that the
+ situation can be rectified automatically.
+
+ 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-Packet
+
+ The Rejected-Packet 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-Packet MUST be truncated to comply with the peer's
+
+
+
+Simpson [Page 34]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+ 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 automaton is in the Opened
+ state, then this MUST be reported back to the peer by transmitting
+ a Protocol-Reject.
+
+ 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.
+
+ 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.
+
+
+
+Simpson [Page 35]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+ 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.
+
+ Upon reception of an Echo-Request in the LCP Opened state, an
+ Echo-Reply MUST be transmitted.
+
+ Echo-Request and Echo-Reply packets MUST 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.
+
+
+
+Simpson [Page 36]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+ 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.
+
+ 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. The end of the field is indicated by the Length.
+
+
+
+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.
+
+ Discard-Request packets MUST only be sent in the LCP Opened state.
+ On reception, the receiver MUST silently discard any Discard-
+ Request that it receives.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 37]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+ 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.
+
+ 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. The end of the field is indicated by the Length.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 38]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+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 field 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.
+
+ Design Philosophy
+
+ The options indicate additional capabilities or requirements of
+ the implementation that is requesting the option. An
+ implementation which does not understand any option SHOULD
+ interoperate with one which implements every option.
+
+ A default is specified for each option which allows the link to
+ correctly function without negotiation of the option, although
+ perhaps with less than optimal performance.
+
+ Except where explicitly specified, acknowledgement of an option
+ does not require the peer to take any additional action other than
+ the default.
+
+ It is not necessary to send the default values for the options in
+ a Configure-Request.
+
+
+ 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 ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+Simpson [Page 39]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+ 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].
+ This document concerns the following values:
+
+ 0 RESERVED
+ 1 Maximum-Receive-Unit
+ 3 Authentication-Protocol
+ 4 Quality-Protocol
+ 5 Magic-Number
+ 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 or unrecognized 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 contains information
+ specific to the Configuration Option. The format and length of
+ the Data field is determined by the Type and Length fields.
+
+ When the Data field is indicated by the Length to extend beyond
+ the end of the Information field, the entire packet is silently
+ discarded without affecting the automaton.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 40]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+6.1. Maximum-Receive-Unit (MRU)
+
+ 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.
+
+ 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.
+
+
+
+
+Simpson [Page 41]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+6.2. 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 protocol for authentication. By default,
+ authentication is not required.
+
+ 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.
+
+ The implementation sending the Configure-Request is indicating
+ that it expects authentication from its peer. If an
+ implementation sends a Configure-Ack, then it is agreeing to
+ authenticate with the specified protocol. An implementation
+ receiving a Configure-Ack 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
+
+
+
+
+
+Simpson [Page 42]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+ 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:
+
+ 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.3. 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.
+
+ The implementation sending the Configure-Request is indicating
+ that it expects to receive monitoring information from its peer.
+ If an implementation sends a Configure-Ack, then it is agreeing to
+ send the specified protocol. An implementation receiving a
+ Configure-Ack SHOULD expect the peer to send the acknowledged
+ protocol.
+
+ There is no requirement that quality monitoring be full-duplex or
+
+
+
+Simpson [Page 43]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+ 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
+
+ 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.
+
+
+
+
+
+
+Simpson [Page 44]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+6.4. 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 a 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.
+ 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-
+
+
+
+Simpson [Page 45]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+ 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, looped-back links 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 when 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
+ 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.
+
+
+
+Simpson [Page 46]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+ 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, 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 looped-back condition is
+ terminated, and Magic-Numbers are successfully negotiated. A more
+ optimistic procedure (in the case of a looped-back link) is to
+ begin transmitting LCP Echo-Request packets until an appropriate
+ Echo-Reply is received, indicating a termination of the looped-
+ 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 always be Nak'd, if it is
+ not Rejected outright.
+
+
+
+
+
+
+
+Simpson [Page 47]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+6.5. Protocol-Field-Compression (PFC)
+
+ 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
+ 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
+
+
+
+Simpson [Page 48]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 49]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+6.6. Address-and-Control-Field-Compression (ACFC)
+
+ 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.
+
+ 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
+
+
+
+
+
+
+
+Simpson [Page 50]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+Security Considerations
+
+ Security issues are briefly discussed in sections concerning the
+ Authentication Phase, the Close event, and the Authentication-
+ Protocol Configuration Option.
+
+
+
+References
+
+ [1] Perkins, D., "Requirements for an Internet Standard Point-to-
+ Point Protocol", RFC 1547, Carnegie Mellon University,
+ December 1993.
+
+ [2] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC
+ 1340, USC/Information Sciences Institute, July 1992.
+
+
+Acknowledgements
+
+ 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@merit.edu mailing list.
+
+ Much of the text in this document is taken from the working group
+ requirements [1]; and RFCs 1171 & 1172, by Drew Perkins while at
+ Carnegie Mellon University, and by Russ Hobby of the University of
+ California at Davis.
+
+ William Simpson was principally responsible for introducing
+ consistent terminology and philosophy, and the re-design of the phase
+ and negotiation state machines.
+
+ Many people spent significant time helping to develop the Point-to-
+ Point Protocol. The complete list of people is too numerous to list,
+ but the following people deserve special thanks: Rick Adams, Ken
+ Adelman, Fred Baker, Mike Ballard, Craig Fox, Karl Fox, Phill Gross,
+ Kory Hamzeh, former WG chair Russ Hobby, David Kaufman, former WG
+ chair Steve Knowles, Mark Lewis, former WG chair Brian Lloyd, John
+ LoVerso, Bill Melohn, Mike Patton, former WG chair Drew Perkins, Greg
+ Satz, John Shriver, Vernon Schryver, and Asher Waldfogel.
+
+ Special thanks to Morning Star Technologies for providing computing
+ resources and network access support for writing this specification.
+
+
+
+
+
+
+
+Simpson [Page 51]
+ RFC 1661 Point-to-Point Protocol July 1994
+
+
+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
+
+ 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
+
+ Bill.Simpson@um.cc.umich.edu
+ bsimpson@MorningStar.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 52]
+
+
diff --git a/rfc/rfc1662.txt b/rfc/rfc1662.txt
new file mode 100644
index 0000000..5a5b214
--- /dev/null
+++ b/rfc/rfc1662.txt
@@ -0,0 +1,1436 @@
+
+
+
+
+
+
+
+Network Working Group W. Simpson, Editor
+Request for Comments: 1662 Daydreamer
+STD: 51 July 1994
+Obsoletes: 1549
+Category: Standards Track
+
+
+ PPP in HDLC-like Framing
+
+
+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.
+
+ This document describes the use of HDLC-like framing for PPP
+ encapsulated packets.
+
+
+Table of Contents
+
+
+ 1. Introduction .......................................... 1
+ 1.1 Specification of Requirements ................... 2
+ 1.2 Terminology ..................................... 2
+
+ 2. Physical Layer Requirements ........................... 3
+
+ 3. The Data Link Layer ................................... 4
+ 3.1 Frame Format .................................... 5
+ 3.2 Modification of the Basic Frame ................. 7
+
+ 4. Octet-stuffed framing ................................. 8
+ 4.1 Flag Sequence ................................... 8
+ 4.2 Transparency .................................... 8
+ 4.3 Invalid Frames .................................. 9
+ 4.4 Time Fill ....................................... 9
+ 4.4.1 Octet-synchronous ............................... 9
+ 4.4.2 Asynchronous .................................... 9
+ 4.5 Transmission Considerations ..................... 10
+ 4.5.1 Octet-synchronous ............................... 10
+ 4.5.2 Asynchronous .................................... 10
+
+
+Simpson [Page i]
+RFC 1662 HDLC-like Framing July 1994
+
+
+ 5. Bit-stuffed framing ................................... 11
+ 5.1 Flag Sequence ................................... 11
+ 5.2 Transparency .................................... 11
+ 5.3 Invalid Frames .................................. 11
+ 5.4 Time Fill ....................................... 11
+ 5.5 Transmission Considerations ..................... 12
+
+ 6. Asynchronous to Synchronous Conversion ................ 13
+
+ 7. Additional LCP Configuration Options .................. 14
+ 7.1 Async-Control-Character-Map (ACCM) .............. 14
+
+ APPENDICES ................................................... 17
+ A. Recommended LCP Options ............................... 17
+ B. Automatic Recognition of PPP Frames ................... 17
+ C. Fast Frame Check Sequence (FCS) Implementation ........ 18
+ C.1 FCS table generator ............................. 18
+ C.2 16-bit FCS Computation Method ................... 19
+ C.3 32-bit FCS Computation Method ................... 21
+
+ SECURITY CONSIDERATIONS ...................................... 24
+ REFERENCES ................................................... 24
+ ACKNOWLEDGEMENTS ............................................. 25
+ CHAIR'S ADDRESS .............................................. 25
+ EDITOR'S ADDRESS ............................................. 25
+
+
+
+
+1. Introduction
+
+ This specification provides for framing over both bit-oriented and
+ octet-oriented synchronous links, and asynchronous links with 8 bits
+ of data and no parity. These links MUST be full-duplex, but MAY be
+ either dedicated or circuit-switched.
+
+ An escape mechanism is specified to allow control data such as
+ XON/XOFF to be transmitted transparently over the link, and to remove
+ spurious control data which may be injected into the link by
+ intervening hardware and software.
+
+ Some protocols expect error free transmission, and either provide
+ error detection only on a conditional basis, or do not provide it at
+ all. PPP uses the HDLC Frame Check Sequence for error detection.
+ This is commonly available in hardware implementations, and a
+ software implementation is provided.
+
+
+
+
+
+
+Simpson [Page 1]
+RFC 1662 HDLC-like Framing July 1994
+
+
+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.
+
+
+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
+ The implementation discards the packet without further
+ processing. The implementation SHOULD provide the
+ capability of logging the error, including the contents of
+ the silently discarded packet, and SHOULD record the event
+ in a statistics counter.
+
+
+Simpson [Page 2]
+RFC 1662 HDLC-like Framing July 1994
+
+
+2. Physical Layer Requirements
+
+ PPP is capable of operating across most DTE/DCE interfaces (such as,
+ EIA RS-232-E, EIA RS-422, and CCITT V.35). The only absolute
+ requirement imposed by PPP is the provision of a full-duplex circuit,
+ either dedicated or circuit-switched, which can operate in either an
+ asynchronous (start/stop), bit-synchronous, or octet-synchronous
+ mode, transparent to PPP Data Link Layer frames.
+
+ Interface Format
+
+ PPP presents an octet interface to the physical layer. There is
+ no provision for sub-octets to be supplied or accepted.
+
+ Transmission Rate
+
+ PPP does not impose any restrictions regarding transmission rate,
+ other than that of the particular DTE/DCE interface.
+
+ Control Signals
+
+ PPP does not require the use of control signals, such as Request
+ To Send (RTS), Clear To Send (CTS), Data Carrier Detect (DCD), and
+ Data Terminal Ready (DTR).
+
+ When available, using such signals can allow greater functionality
+ and performance. In particular, such signals SHOULD be used to
+ signal the Up and Down events in the LCP Option Negotiation
+ Automaton [1]. When such signals are not available, the
+ implementation MUST signal the Up event to LCP upon
+ initialization, and SHOULD NOT signal the Down event.
+
+ Because signalling is not required, the physical layer MAY be
+ decoupled from the data link layer, hiding the transient details
+ of the physical transport. This has implications for mobility in
+ cellular radio networks, and other rapidly switching links.
+
+ When moving from cell to cell within the same zone, an
+ implementation MAY choose to treat the entire zone as a single
+ link, even though transmission is switched among several
+ frequencies. The link is considered to be with the central
+ control unit for the zone, rather than the individual cell
+ transceivers. However, the link SHOULD re-establish its
+ configuration whenever the link is switched to a different
+ administration.
+
+ Due to the bursty nature of data traffic, some implementations
+ have choosen to disconnect the physical layer during periods of
+
+
+
+Simpson [Page 3]
+RFC 1662 HDLC-like Framing July 1994
+
+
+ inactivity, and reconnect when traffic resumes, without informing
+ the data link layer. Robust implementations should avoid using
+ this trick over-zealously, since the price for decreased setup
+ latency is decreased security. Implementations SHOULD signal the
+ Down event whenever "significant time" has elapsed since the link
+ was disconnected. The value for "significant time" is a matter of
+ considerable debate, and is based on the tariffs, call setup
+ times, and security concerns of the installation.
+
+
+
+3. The Data Link Layer
+
+ PPP uses the principles described in ISO 3309-1979 HDLC frame
+ structure, most recently the fourth edition 3309:1991 [2], which
+ specifies modifications to allow HDLC use in asynchronous
+ environments.
+
+ The PPP control procedures use the Control field encodings described
+ in ISO 4335-1979 HDLC elements of procedures, most recently the
+ fourth edition 4335:1991 [4].
+
+ This should not be construed to indicate that every feature of the
+ above recommendations are included in PPP. Each feature included
+ is explicitly described in the following sections.
+
+ To remain consistent with standard Internet practice, and avoid
+ confusion for people used to reading RFCs, all binary numbers in the
+ following descriptions are in Most Significant Bit to Least
+ Significant Bit order, reading from left to right, unless otherwise
+ indicated. Note that this is contrary to standard ISO and CCITT
+ practice which orders bits as transmitted (network bit order). Keep
+ this in mind when comparing this document with the international
+ standards documents.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 4]
+RFC 1662 HDLC-like Framing July 1994
+
+
+3.1. Frame Format
+
+ A summary of the PPP HDLC-like frame structure is shown below. This
+ figure does not include bits inserted for synchronization (such as
+ start and stop bits for asynchronous links), nor any bits or octets
+ inserted for transparency. The fields are transmitted from left to
+ right.
+
+ +----------+----------+----------+
+ | Flag | Address | Control |
+ | 01111110 | 11111111 | 00000011 |
+ +----------+----------+----------+
+ +----------+-------------+---------+
+ | Protocol | Information | Padding |
+ | 8/16 bits| * | * |
+ +----------+-------------+---------+
+ +----------+----------+-----------------
+ | FCS | Flag | Inter-frame Fill
+ |16/32 bits| 01111110 | or next Address
+ +----------+----------+-----------------
+
+ The Protocol, Information and Padding fields are described in the
+ Point-to-Point Protocol Encapsulation [1].
+
+ Flag Sequence
+
+ Each frame begins and ends with a Flag Sequence, which is the
+ binary sequence 01111110 (hexadecimal 0x7e). All implementations
+ continuously check for this flag, which is used for frame
+ synchronization.
+
+ Only one Flag Sequence is required between two frames. Two
+ consecutive Flag Sequences constitute an empty frame, which is
+ silently discarded, and not counted as a FCS error.
+
+ Address Field
+
+ The Address field is a single octet, which contains the binary
+ sequence 11111111 (hexadecimal 0xff), the All-Stations address.
+ Individual station addresses are not assigned. The All-Stations
+ address MUST always be recognized and received.
+
+ The use of other address lengths and values may be defined at a
+ later time, or by prior agreement. Frames with unrecognized
+ Addresses SHOULD be silently discarded.
+
+
+
+
+
+
+Simpson [Page 5]
+RFC 1662 HDLC-like Framing July 1994
+
+
+ Control Field
+
+ The Control field is a single octet, which contains the binary
+ sequence 00000011 (hexadecimal 0x03), the Unnumbered Information
+ (UI) command with the Poll/Final (P/F) bit set to zero.
+
+ The use of other Control field values may be defined at a later
+ time, or by prior agreement. Frames with unrecognized Control
+ field values SHOULD be silently discarded.
+
+ Frame Check Sequence (FCS) Field
+
+ The Frame Check Sequence field defaults to 16 bits (two octets).
+ The FCS is transmitted least significant octet first, which
+ contains the coefficient of the highest term.
+
+ A 32-bit (four octet) FCS is also defined. Its use may be
+ negotiated as described in "PPP LCP Extensions" [5].
+
+ The use of other FCS lengths may be defined at a later time, or by
+ prior agreement.
+
+ The FCS field is calculated over all bits of the Address, Control,
+ Protocol, Information and Padding fields, not including any start
+ and stop bits (asynchronous) nor any bits (synchronous) or octets
+ (asynchronous or synchronous) inserted for transparency. This
+ also does not include the Flag Sequences nor the FCS field itself.
+
+ When octets are received which are flagged in the Async-
+ Control-Character-Map, they are discarded before calculating
+ the FCS.
+
+ For more information on the specification of the FCS, see the
+ Appendices.
+
+ The end of the Information and Padding fields is found by locating
+ the closing Flag Sequence and removing the Frame Check Sequence
+ field.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 6]
+RFC 1662 HDLC-like Framing July 1994
+
+
+3.2. Modification of the Basic Frame
+
+ The Link Control Protocol can negotiate modifications to the standard
+ HDLC-like frame structure. However, modified frames will always be
+ clearly distinguishable from standard frames.
+
+ Address-and-Control-Field-Compression
+
+ When using the standard HDLC-like framing, the Address and Control
+ fields contain the hexadecimal values 0xff and 0x03 respectively.
+ When other Address or Control field values are in use, Address-
+ and-Control-Field-Compression MUST NOT be negotiated.
+
+ On transmission, compressed Address and Control fields are simply
+ omitted.
+
+ 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.
+
+ By definition, the first octet of a two octet Protocol field
+ will never be 0xff (since it is not even). The Protocol field
+ value 0x00ff is not allowed (reserved) to avoid ambiguity when
+ Protocol-Field-Compression is enabled and the first Information
+ field octet is 0x03.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 7]
+RFC 1662 HDLC-like Framing July 1994
+
+
+4. Octet-stuffed framing
+
+ This chapter summarizes the use of HDLC-like framing with 8-bit
+ asynchronous and octet-synchronous links.
+
+
+
+4.1. Flag Sequence
+
+ The Flag Sequence indicates the beginning or end of a frame. The
+ octet stream is examined on an octet-by-octet basis for the value
+ 01111110 (hexadecimal 0x7e).
+
+
+
+4.2. Transparency
+
+ An octet stuffing procedure is used. The Control Escape octet is
+ defined as binary 01111101 (hexadecimal 0x7d), most significant bit
+ first.
+
+ As a minimum, sending implementations MUST escape the Flag Sequence
+ and Control Escape octets.
+
+ After FCS computation, the transmitter examines the entire frame
+ between the two Flag Sequences. Each Flag Sequence, Control Escape
+ octet, and any octet which is flagged in the sending Async-Control-
+ Character-Map (ACCM), is replaced by a two octet sequence consisting
+ of the Control Escape octet followed by the original octet
+ exclusive-or'd with hexadecimal 0x20.
+
+ This is bit 5 complemented, where the bit positions are numbered
+ 76543210 (the 6th bit as used in ISO numbered 87654321 -- BEWARE
+ when comparing documents).
+
+ Receiving implementations MUST correctly process all Control Escape
+ sequences.
+
+ On reception, prior to FCS computation, each octet with value less
+ than hexadecimal 0x20 is checked. If it is flagged in the receiving
+ ACCM, it is simply removed (it may have been inserted by intervening
+ data communications equipment). Each Control Escape octet is also
+ removed, and the following octet is exclusive-or'd with hexadecimal
+ 0x20, unless it is the Flag Sequence (which aborts a frame).
+
+ A few examples may make this more clear. Escaped data is transmitted
+ on the link as follows:
+
+
+
+
+Simpson [Page 8]
+RFC 1662 HDLC-like Framing July 1994
+
+
+
+ 0x7e is encoded as 0x7d, 0x5e. (Flag Sequence)
+ 0x7d is encoded as 0x7d, 0x5d. (Control Escape)
+ 0x03 is encoded as 0x7d, 0x23. (ETX)
+
+ Some modems with software flow control may intercept outgoing DC1 and
+ DC3 ignoring the 8th (parity) bit. This data would be transmitted on
+ the link as follows:
+
+ 0x11 is encoded as 0x7d, 0x31. (XON)
+ 0x13 is encoded as 0x7d, 0x33. (XOFF)
+ 0x91 is encoded as 0x7d, 0xb1. (XON with parity set)
+ 0x93 is encoded as 0x7d, 0xb3. (XOFF with parity set)
+
+
+
+
+4.3. Invalid Frames
+
+ Frames which are too short (less than 4 octets when using the 16-bit
+ FCS), or which end with a Control Escape octet followed immediately
+ by a closing Flag Sequence, or in which octet-framing is violated (by
+ transmitting a "0" stop bit where a "1" bit is expected), are
+ silently discarded, and not counted as a FCS error.
+
+
+
+4.4. Time Fill
+
+4.4.1. Octet-synchronous
+
+ There is no provision for inter-octet time fill.
+
+ The Flag Sequence MUST be transmitted during inter-frame time fill.
+
+
+4.4.2. Asynchronous
+
+ Inter-octet time fill MUST be accomplished by transmitting continuous
+ "1" bits (mark-hold state).
+
+ Inter-frame time fill can be viewed as extended inter-octet time
+ fill. Doing so can save one octet for every frame, decreasing delay
+ and increasing bandwidth. This is possible since a Flag Sequence may
+ serve as both a frame end and a frame begin. After having received
+ any frame, an idle receiver will always be in a frame begin state.
+
+
+
+
+Simpson [Page 9]
+RFC 1662 HDLC-like Framing July 1994
+
+
+ Robust transmitters should avoid using this trick over-zealously,
+ since the price for decreased delay is decreased reliability. Noisy
+ links may cause the receiver to receive garbage characters and
+ interpret them as part of an incoming frame. If the transmitter does
+ not send a new opening Flag Sequence before sending the next frame,
+ then that frame will be appended to the noise characters causing an
+ invalid frame (with high reliability).
+
+ It is suggested that implementations will achieve the best results by
+ always sending an opening Flag Sequence if the new frame is not
+ back-to-back with the last. Transmitters SHOULD send an open Flag
+ Sequence whenever "appreciable time" has elapsed after the prior
+ closing Flag Sequence. The maximum value for "appreciable time" is
+ likely to be no greater than the typing rate of a slow typist, about
+ 1 second.
+
+
+
+4.5. Transmission Considerations
+
+4.5.1. Octet-synchronous
+
+ The definition of various encodings and scrambling is the
+ responsibility of the DTE/DCE equipment in use, and is outside the
+ scope of this specification.
+
+
+4.5.2. Asynchronous
+
+ All octets are transmitted least significant bit first, with one
+ start bit, eight bits of data, and one stop bit. There is no
+ provision for seven bit asynchronous links.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 10]
+RFC 1662 HDLC-like Framing July 1994
+
+
+5. Bit-stuffed framing
+
+ This chapter summarizes the use of HDLC-like framing with bit-
+ synchronous links.
+
+
+
+5.1. Flag Sequence
+
+ The Flag Sequence indicates the beginning or end of a frame, and is
+ used for frame synchronization. The bit stream is examined on a
+ bit-by-bit basis for the binary sequence 01111110 (hexadecimal 0x7e).
+
+ The "shared zero mode" Flag Sequence "011111101111110" SHOULD NOT be
+ used. When not avoidable, such an implementation MUST ensure that
+ the first Flag Sequence detected (the end of the frame) is promptly
+ communicated to the link layer. Use of the shared zero mode hinders
+ interoperability with bit-synchronous to asynchronous and bit-
+ synchronous to octet-synchronous converters.
+
+
+
+5.2. Transparency
+
+ After FCS computation, the transmitter examines the entire frame
+ between the two Flag Sequences. A "0" bit is inserted after all
+ sequences of five contiguous "1" bits (including the last 5 bits of
+ the FCS) to ensure that a Flag Sequence is not simulated.
+
+ On reception, prior to FCS computation, any "0" bit that directly
+ follows five contiguous "1" bits is discarded.
+
+
+
+5.3. Invalid Frames
+
+ Frames which are too short (less than 4 octets when using the 16-bit
+ FCS), or which end with a sequence of more than six "1" bits, are
+ silently discarded, and not counted as a FCS error.
+
+
+
+5.4. Time Fill
+
+ There is no provision for inter-octet time fill.
+
+ The Flag Sequence SHOULD be transmitted during inter-frame time fill.
+ However, certain types of circuit-switched links require the use of
+
+
+
+Simpson [Page 11]
+RFC 1662 HDLC-like Framing July 1994
+
+
+ mark idle (continuous ones), particularly those that calculate
+ accounting based on periods of bit activity. When mark idle is used
+ on a bit-synchronous link, the implementation MUST ensure at least 15
+ consecutive "1" bits between Flags during the idle period, and that
+ the Flag Sequence is always generated at the beginning of a frame
+ after an idle period.
+
+ This differs from practice in ISO 3309, which allows 7 to 14 bit
+ mark idle.
+
+
+
+5.5. Transmission Considerations
+
+ All octets are transmitted least significant bit first.
+
+ The definition of various encodings and scrambling is the
+ responsibility of the DTE/DCE equipment in use, and is outside the
+ scope of this specification.
+
+ While PPP will operate without regard to the underlying
+ representation of the bit stream, lack of standards for transmission
+ will hinder interoperability as surely as lack of data link
+ standards. At speeds of 56 Kbps through 2.0 Mbps, NRZ is currently
+ most widely available, and on that basis is recommended as a default.
+
+ When configuration of the encoding is allowed, NRZI is recommended as
+ an alternative, because of its relative immunity to signal inversion
+ configuration errors, and instances when it MAY allow connection
+ without an expensive DSU/CSU. Unfortunately, NRZI encoding
+ exacerbates the missing x1 factor of the 16-bit FCS, so that one
+ error in 2**15 goes undetected (instead of one in 2**16), and triple
+ errors are not detected. Therefore, when NRZI is in use, it is
+ recommended that the 32-bit FCS be negotiated, which includes the x1
+ factor.
+
+ At higher speeds of up to 45 Mbps, some implementors have chosen the
+ ANSI High Speed Synchronous Interface [HSSI]. While this experience
+ is currently limited, implementors are encouraged to cooperate in
+ choosing transmission encoding.
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 12]
+RFC 1662 HDLC-like Framing July 1994
+
+
+6. Asynchronous to Synchronous Conversion
+
+ There may be some use of asynchronous-to-synchronous converters (some
+ built into modems and cellular interfaces), resulting in an
+ asynchronous PPP implementation on one end of a link and a
+ synchronous implementation on the other. It is the responsibility of
+ the converter to do all stuffing conversions during operation.
+
+ To enable this functionality, synchronous PPP implementations MUST
+ always respond to the Async-Control-Character-Map Configuration
+ Option with the LCP Configure-Ack. However, acceptance of the
+ Configuration Option does not imply that the synchronous
+ implementation will do any ACCM mapping. Instead, all such octet
+ mapping will be performed by the asynchronous-to-synchronous
+ converter.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 13]
+RFC 1662 HDLC-like Framing July 1994
+
+
+7. 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 [10]. This document concerns the
+ following values:
+
+ 2 Async-Control-Character-Map
+
+
+
+
+7.1. Async-Control-Character-Map (ACCM)
+
+ Description
+
+ This Configuration Option provides a method to negotiate the use
+ of control character transparency on asynchronous links.
+
+ Each end of the asynchronous link maintains two Async-Control-
+ Character-Maps. The receiving ACCM is 32 bits, but the sending
+ ACCM may be up to 256 bits. This results in four distinct ACCMs,
+ two in each direction of the link.
+
+ For asynchronous links, the default receiving ACCM is 0xffffffff.
+ The default sending ACCM is 0xffffffff, plus the Control Escape
+ and Flag Sequence characters themselves, plus whatever other
+ outgoing characters are flagged (by prior configuration) as likely
+ to be intercepted.
+
+ For other types of links, the default value is 0, since there is
+ no need for mapping.
+
+ The default inclusion of all octets less than hexadecimal 0x20
+ allows all ASCII control characters [6] excluding DEL (Delete)
+ to be transparently communicated through all known data
+ communications equipment.
+
+ The transmitter MAY also send octets with values in the range 0x40
+ through 0xff (except 0x5e) in Control Escape format. Since these
+ octet values are not negotiable, this does not solve the problem
+ of receivers which cannot handle all non-control characters.
+ Also, since the technique does not affect the 8th bit, this does
+ not solve problems for communications links that can send only 7-
+ bit characters.
+
+
+
+
+Simpson [Page 14]
+RFC 1662 HDLC-like Framing July 1994
+
+
+ Note that this specification differs in detail from later
+ amendments, such as 3309:1991/Amendment 2 [3]. However, such
+ "extended transparency" is applied only by "prior agreement".
+ Use of the transparency methods in this specification
+ constitute a prior agreement with respect to PPP.
+
+ For compatibility with 3309:1991/Amendment 2, the transmitter
+ MAY escape DEL and ACCM equivalents with the 8th (most
+ significant) bit set. No change is required in the receiving
+ algorithm.
+
+ Following ACCM negotiation, the transmitter SHOULD cease
+ escaping DEL.
+
+ 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.
+
+ 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 | ACCM
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ACCM (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ Type
+
+ 2
+
+ Length
+
+ 6
+
+
+
+
+
+
+Simpson [Page 15]
+RFC 1662 HDLC-like Framing July 1994
+
+
+ ACCM
+
+ The ACCM 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 16]
+RFC 1662 HDLC-like Framing July 1994
+
+
+A. Recommended LCP Options
+
+ The following Configurations Options are recommended:
+
+ High Speed links
+
+ Magic Number
+ Link Quality Monitoring
+ No Address and Control Field Compression
+ No Protocol Field Compression
+
+
+ Low Speed or Asynchronous links
+
+ Async Control Character Map
+ Magic Number
+ Address and Control Field Compression
+ Protocol Field Compression
+
+
+
+B. Automatic Recognition of PPP Frames
+
+ It is sometimes desirable to detect PPP frames, for example during a
+ login sequence. The following octet sequences all begin valid PPP
+ LCP frames:
+
+ 7e ff 03 c0 21
+ 7e ff 7d 23 c0 21
+ 7e 7d df 7d 23 c0 21
+
+ Note that the first two forms are not a valid username for Unix.
+ However, only the third form generates a correctly checksummed PPP
+ frame, whenever 03 and ff are taken as the control characters ETX and
+ DEL without regard to parity (they are correct for an even parity
+ link) and discarded.
+
+ Many implementations deal with this by putting the interface into
+ packet mode when one of the above username patterns are detected
+ during login, without examining the initial PPP checksum. The
+ initial incoming PPP frame is discarded, but a Configure-Request is
+ sent immediately.
+
+
+
+
+
+
+
+
+
+Simpson [Page 17]
+RFC 1662 HDLC-like Framing July 1994
+
+
+C. Fast Frame Check Sequence (FCS) Implementation
+
+ The FCS was originally designed with hardware implementations in
+ mind. A serial bit stream is transmitted on the wire, the FCS is
+ calculated over the serial data as it goes out, and the complement of
+ the resulting FCS is appended to the serial stream, followed by the
+ Flag Sequence.
+
+ The receiver has no way of determining that it has finished
+ calculating the received FCS until it detects the Flag Sequence.
+ Therefore, the FCS was designed so that a particular pattern results
+ when the FCS operation passes over the complemented FCS. A good
+ frame is indicated by this "good FCS" value.
+
+
+
+C.1. FCS table generator
+
+ The following code creates the lookup table used to calculate the
+ FCS-16.
+
+ /*
+ * Generate a FCS-16 table.
+ *
+ * Drew D. Perkins at Carnegie Mellon University.
+ *
+ * Code liberally borrowed from Mohsen Banan and D. Hugh Redelmeier.
+ */
+
+ /*
+ * The FCS-16 generator polynomial: x**0 + x**5 + x**12 + x**16.
+ */
+ #define P 0x8408
+
+
+ main()
+ {
+ register unsigned int b, v;
+ register int i;
+
+ printf("typedef unsigned short u16;\n");
+ printf("static u16 fcstab[256] = {");
+ for (b = 0; ; ) {
+ if (b % 8 == 0)
+ printf("\n");
+
+ v = b;
+ for (i = 8; i--; )
+
+
+
+Simpson [Page 18]
+RFC 1662 HDLC-like Framing July 1994
+
+
+ v = v & 1 ? (v >> 1) ^ P : v >> 1;
+
+ printf("\t0x%04x", v & 0xFFFF);
+ if (++b == 256)
+ break;
+ printf(",");
+ }
+ printf("\n};\n");
+ }
+
+
+
+C.2. 16-bit FCS Computation Method
+
+ The following code provides a table lookup computation for
+ calculating the Frame Check Sequence as data arrives at the
+ interface. This implementation is based on [7], [8], and [9].
+
+ /*
+ * u16 represents an unsigned 16-bit number. Adjust the typedef for
+ * your hardware.
+ */
+ typedef unsigned short u16;
+
+ /*
+ * FCS lookup table as calculated by the table generator.
+ */
+ static u16 fcstab[256] = {
+ 0x0000, 0x1189, 0x2312, 0x329b, 0x4624, 0x57ad, 0x6536, 0x74bf,
+ 0x8c48, 0x9dc1, 0xaf5a, 0xbed3, 0xca6c, 0xdbe5, 0xe97e, 0xf8f7,
+ 0x1081, 0x0108, 0x3393, 0x221a, 0x56a5, 0x472c, 0x75b7, 0x643e,
+ 0x9cc9, 0x8d40, 0xbfdb, 0xae52, 0xdaed, 0xcb64, 0xf9ff, 0xe876,
+ 0x2102, 0x308b, 0x0210, 0x1399, 0x6726, 0x76af, 0x4434, 0x55bd,
+ 0xad4a, 0xbcc3, 0x8e58, 0x9fd1, 0xeb6e, 0xfae7, 0xc87c, 0xd9f5,
+ 0x3183, 0x200a, 0x1291, 0x0318, 0x77a7, 0x662e, 0x54b5, 0x453c,
+ 0xbdcb, 0xac42, 0x9ed9, 0x8f50, 0xfbef, 0xea66, 0xd8fd, 0xc974,
+ 0x4204, 0x538d, 0x6116, 0x709f, 0x0420, 0x15a9, 0x2732, 0x36bb,
+ 0xce4c, 0xdfc5, 0xed5e, 0xfcd7, 0x8868, 0x99e1, 0xab7a, 0xbaf3,
+ 0x5285, 0x430c, 0x7197, 0x601e, 0x14a1, 0x0528, 0x37b3, 0x263a,
+ 0xdecd, 0xcf44, 0xfddf, 0xec56, 0x98e9, 0x8960, 0xbbfb, 0xaa72,
+ 0x6306, 0x728f, 0x4014, 0x519d, 0x2522, 0x34ab, 0x0630, 0x17b9,
+ 0xef4e, 0xfec7, 0xcc5c, 0xddd5, 0xa96a, 0xb8e3, 0x8a78, 0x9bf1,
+ 0x7387, 0x620e, 0x5095, 0x411c, 0x35a3, 0x242a, 0x16b1, 0x0738,
+ 0xffcf, 0xee46, 0xdcdd, 0xcd54, 0xb9eb, 0xa862, 0x9af9, 0x8b70,
+ 0x8408, 0x9581, 0xa71a, 0xb693, 0xc22c, 0xd3a5, 0xe13e, 0xf0b7,
+ 0x0840, 0x19c9, 0x2b52, 0x3adb, 0x4e64, 0x5fed, 0x6d76, 0x7cff,
+ 0x9489, 0x8500, 0xb79b, 0xa612, 0xd2ad, 0xc324, 0xf1bf, 0xe036,
+ 0x18c1, 0x0948, 0x3bd3, 0x2a5a, 0x5ee5, 0x4f6c, 0x7df7, 0x6c7e,
+
+
+
+Simpson [Page 19]
+RFC 1662 HDLC-like Framing July 1994
+
+
+ 0xa50a, 0xb483, 0x8618, 0x9791, 0xe32e, 0xf2a7, 0xc03c, 0xd1b5,
+ 0x2942, 0x38cb, 0x0a50, 0x1bd9, 0x6f66, 0x7eef, 0x4c74, 0x5dfd,
+ 0xb58b, 0xa402, 0x9699, 0x8710, 0xf3af, 0xe226, 0xd0bd, 0xc134,
+ 0x39c3, 0x284a, 0x1ad1, 0x0b58, 0x7fe7, 0x6e6e, 0x5cf5, 0x4d7c,
+ 0xc60c, 0xd785, 0xe51e, 0xf497, 0x8028, 0x91a1, 0xa33a, 0xb2b3,
+ 0x4a44, 0x5bcd, 0x6956, 0x78df, 0x0c60, 0x1de9, 0x2f72, 0x3efb,
+ 0xd68d, 0xc704, 0xf59f, 0xe416, 0x90a9, 0x8120, 0xb3bb, 0xa232,
+ 0x5ac5, 0x4b4c, 0x79d7, 0x685e, 0x1ce1, 0x0d68, 0x3ff3, 0x2e7a,
+ 0xe70e, 0xf687, 0xc41c, 0xd595, 0xa12a, 0xb0a3, 0x8238, 0x93b1,
+ 0x6b46, 0x7acf, 0x4854, 0x59dd, 0x2d62, 0x3ceb, 0x0e70, 0x1ff9,
+ 0xf78f, 0xe606, 0xd49d, 0xc514, 0xb1ab, 0xa022, 0x92b9, 0x8330,
+ 0x7bc7, 0x6a4e, 0x58d5, 0x495c, 0x3de3, 0x2c6a, 0x1ef1, 0x0f78
+ };
+
+ #define PPPINITFCS16 0xffff /* Initial FCS value */
+ #define PPPGOODFCS16 0xf0b8 /* Good final FCS value */
+
+ /*
+ * Calculate a new fcs given the current fcs and the new data.
+ */
+ u16 pppfcs16(fcs, cp, len)
+ register u16 fcs;
+ register unsigned char *cp;
+ register int len;
+ {
+ ASSERT(sizeof (u16) == 2);
+ ASSERT(((u16) -1) > 0);
+ while (len--)
+ fcs = (fcs >> 8) ^ fcstab[(fcs ^ *cp++) & 0xff];
+
+ return (fcs);
+ }
+
+ /*
+ * How to use the fcs
+ */
+ tryfcs16(cp, len)
+ register unsigned char *cp;
+ register int len;
+ {
+ u16 trialfcs;
+
+ /* add on output */
+ trialfcs = pppfcs16( PPPINITFCS16, cp, len );
+ trialfcs ^= 0xffff; /* complement */
+ cp[len] = (trialfcs & 0x00ff); /* least significant byte first */
+ cp[len+1] = ((trialfcs >> 8) & 0x00ff);
+
+
+
+
+Simpson [Page 20]
+RFC 1662 HDLC-like Framing July 1994
+
+
+ /* check on input */
+ trialfcs = pppfcs16( PPPINITFCS16, cp, len + 2 );
+ if ( trialfcs == PPPGOODFCS16 )
+ printf("Good FCS\n");
+ }
+
+
+
+C.3. 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.
+
+ /*
+ * The FCS-32 generator polynomial: x**0 + x**1 + x**2 + x**4 + x**5
+ * + x**7 + x**8 + x**10 + x**11 + x**12 + x**16
+ * + x**22 + x**23 + x**26 + x**32.
+ */
+
+ /*
+ * 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,
+
+
+
+Simpson [Page 21]
+RFC 1662 HDLC-like Framing July 1994
+
+
+ 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,
+ 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 */
+
+
+
+Simpson [Page 22]
+RFC 1662 HDLC-like Framing July 1994
+
+
+ /*
+ * 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--)
+ 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");
+ }
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 23]
+RFC 1662 HDLC-like Framing July 1994
+
+
+Security Considerations
+
+ As noted in the Physical Layer Requirements section, the link layer
+ might not be informed when the connected state of the physical layer
+ has changed. This results in possible security lapses due to over-
+ reliance on the integrity and security of switching systems and
+ administrations. An insertion attack might be undetected. An
+ attacker which is able to spoof the same calling identity might be
+ able to avoid link authentication.
+
+
+
+References
+
+ [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)",
+ STD 50, RFC 1661, Daydreamer, July 1994.
+
+ [2] ISO/IEC 3309:1991(E), "Information Technology -
+ Telecommunications and information exchange between systems -
+ High-level data link control (HDLC) procedures - Frame
+ structure", International Organization For Standardization,
+ Fourth edition 1991-06-01.
+
+ [3] ISO/IEC 3309:1991/Amd.2:1992(E), "Information Technology -
+ Telecommunications and information exchange between systems -
+ High-level data link control (HDLC) procedures - Frame
+ structure - Amendment 2: Extended transparency options for
+ start/stop transmission", International Organization For
+ Standardization, 1992-01-15.
+
+ [4] ISO/IEC 4335:1991(E), "Information Technology -
+ Telecommunications and information exchange between systems -
+ High-level data link control (HDLC) procedures - Elements of
+ procedures", International Organization For Standardization,
+ Fourth edition 1991-09-15.
+
+ [5] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570,
+ Daydreamer, January 1994.
+
+ [6] ANSI X3.4-1977, "American National Standard Code for
+ Information Interchange", American National Standards
+ Institute, 1977.
+
+ [7] Perez, "Byte-wise CRC Calculations", IEEE Micro, June 1983.
+
+ [8] Morse, G., "Calculating CRC's by Bits and Bytes", Byte,
+ September 1986.
+
+
+
+
+Simpson [Page 24]
+RFC 1662 HDLC-like Framing July 1994
+
+
+ [9] LeVan, J., "A Fast CRC", Byte, November 1987.
+
+ [10] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
+ 1340, USC/Information Sciences Institute, July 1992.
+
+
+
+Acknowledgements
+
+ 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@merit.edu mailing list.
+
+ This specification is based on previous RFCs, where many
+ contributions have been acknowleged.
+
+ The 32-bit FCS example code was provided by Karl Fox (Morning Star
+ Technologies).
+
+ 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
+
+ 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
+
+ Bill.Simpson@um.cc.umich.edu
+ bsimpson@MorningStar.com
+
+
+Simpson [Page 25]
diff --git a/rfc/rfc1701.txt b/rfc/rfc1701.txt
new file mode 100644
index 0000000..60a0e9b
--- /dev/null
+++ b/rfc/rfc1701.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group S. Hanks
+Request for Comments: 1701 NetSmiths, Ltd.
+Category: Informational T. Li
+ D. Farinacci
+ P. Traina
+ cisco Systems
+ October 1994
+
+
+ Generic Routing Encapsulation (GRE)
+
+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
+
+ This document specifies a protocol for performing encapsulation of an
+ arbitrary network layer protocol over another arbitrary network layer
+ protocol.
+
+Introduction
+
+ A number of different proposals [RFC 1234, RFC 1226] currently exist
+ for the encapsulation of one protocol over another protocol. Other
+ types of encapsulations [RFC 1241, SDRP, RFC 1479] have been proposed
+ for transporting IP over IP for policy purposes. This memo describes
+ a protocol which is very similar to, but is more general than, the
+ above proposals. In attempting to be more general, many protocol
+ specific nuances have been ignored. The result is that this proposal
+ is may be less suitable for a situation where a specific "X over Y"
+ encapsulation has been described. It is the attempt of this protocol
+ to provide a simple, general purpose mechanism which is reduces the
+ problem of encapsulation from its current O(n^2) problem to a more
+ manageable state. This proposal also attempts to provide a
+ lightweight encapsulation for use in policy based routing. This memo
+ explicitly does not address the issue of when a packet should be
+ encapsulated. This memo acknowledges, but does not address problems
+ with mutual encapsulation [RFC 1326].
+
+ In the most general case, a system has a packet that needs to be
+ encapsulated and routed. We will call this the payload packet. The
+ payload is first encapsulated in a GRE packet, which possibly also
+ includes a route. The resulting GRE packet can then be encapsulated
+ in some other protocol and then forwarded. We will call this outer
+
+
+
+Hanks, Li, Farinacci & Traina [Page 1]
+
+RFC 1701 Generic Routing Encapsulation (GRE) October 1994
+
+
+ protocol the delivery protocol. The algorithms for processing this
+ packet are discussed later.
+
+Overall packet
+
+ The entire encapsulated packet would then have the form:
+
+ ---------------------------------
+ | |
+ | Delivery Header |
+ | |
+ ---------------------------------
+ | |
+ | GRE Header |
+ | |
+ ---------------------------------
+ | |
+ | Payload packet |
+ | |
+ ---------------------------------
+
+Packet header
+
+ The GRE packet header has the form:
+
+ 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| Flags | Ver | Protocol Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Checksum (optional) | Offset (optional) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Key (optional) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Sequence Number (optional) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Routing (optional)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Flags and version (2 octets)
+
+ The GRE flags are encoded in the first two octets. Bit 0 is the
+ most significant bit, bit 15 is the least significant bit. Bits
+ 13 through 15 are reserved for the Version field. Bits 5 through
+ 12 are reserved for future use and MUST be transmitted as zero.
+
+
+
+
+
+
+Hanks, Li, Farinacci & Traina [Page 2]
+
+RFC 1701 Generic Routing Encapsulation (GRE) October 1994
+
+
+ Checksum Present (bit 0)
+
+ If the Checksum Present bit is set to 1, then the Checksum field
+ is present and contains valid information.
+
+ If either the Checksum Present bit or the Routing Present bit are
+ set, BOTH the Checksum and Offset fields are present in the GRE
+ packet.
+
+ Routing Present (bit 1)
+
+ If the Routing Present bit is set to 1, then it indicates that the
+ Offset and Routing fields are present and contain valid
+ information.
+
+ If either the Checksum Present bit or the Routing Present bit are
+ set, BOTH the Checksum and Offset fields are present in the GRE
+ packet.
+
+ Key Present (bit 2)
+
+ If the Key Present bit is set to 1, then it indicates that the Key
+ field is present in the GRE header. Otherwise, the Key field is
+ not present in the GRE header.
+
+ Sequence Number Present (bit 3)
+
+ If the Sequence Number Present bit is set to 1, then it indicates
+ that the Sequence Number field is present. Otherwise, the
+ Sequence Number field is not present in the GRE header.
+
+ Strict Source Route (bit 4)
+
+ The meaning of the Strict Source route bit is defined in other
+ documents. It is recommended that this bit only be set to 1 if
+ all of the the Routing Information consists of Strict Source
+ Routes.
+
+ Recursion Control (bits 5-7)
+
+ Recursion control contains a three bit unsigned integer which
+ contains the number of additional encapsulations which are
+ permissible. This SHOULD default to zero.
+
+ Version Number (bits 13-15)
+
+ The Version Number field MUST contain the value 0. Other values
+ are outside of the scope of this document.
+
+
+
+Hanks, Li, Farinacci & Traina [Page 3]
+
+RFC 1701 Generic Routing Encapsulation (GRE) October 1994
+
+
+ Protocol Type (2 octets)
+
+ The Protocol Type field contains the protocol type of the payload
+ packet. In general, the value will be the Ethernet protocol type
+ field for the packet. Currently defined protocol types are listed
+ below. Additional values may be defined in other documents.
+
+ Offset (2 octets)
+
+ The offset field indicates the octet offset from the start of the
+ Routing field to the first octet of the active Source Route Entry
+ to be examined. This field is present if the Routing Present or
+ the Checksum Present bit is set to 1, and contains valid
+ information only if the Routing Present bit is set to 1.
+
+ Checksum (2 octets)
+
+ The Checksum field contains the IP (one's complement) checksum of
+ the GRE header and the payload packet. This field is present if
+ the Routing Present or the Checksum Present bit is set to 1, and
+ contains valid information only if the Checksum Present bit is set
+ to 1.
+
+ Key (4 octets)
+
+ The Key field contains a four octet number which was inserted by
+ the encapsulator. It may be used by the receiver to authenticate
+ the source of the packet. The techniques for determining
+ authenticity are outside of the scope of this document. The Key
+ field is only present if the Key Present field is set to 1.
+
+ Sequence Number (4 octets)
+
+ The Sequence Number field contains an unsigned 32 bit integer
+ which is inserted by the encapsulator. It may be used by the
+ receiver to establish the order in which packets have been
+ transmitted from the encapsulator to the receiver. The exact
+ algorithms for the generation of the Sequence Number and the
+ semantics of their reception is outside of the scope of this
+ document.
+
+ Routing (variable)
+
+ The Routing field is optional and is present only if the Routing
+ Present bit is set to 1.
+
+
+
+
+
+
+Hanks, Li, Farinacci & Traina [Page 4]
+
+RFC 1701 Generic Routing Encapsulation (GRE) October 1994
+
+
+ The Routing field is a list of Source Route Entries (SREs). Each
+ SRE has the form:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Address Family | SRE Offset | SRE Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Routing Information ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The routing field is terminated with a "NULL" SRE containing an
+ address family of type 0x0000 and a length of 0.
+
+ Address Family (2 octets)
+
+ The Address Family field contains a two octet value which indicates
+ the syntax and semantics of the Routing Information field. The
+ values for this field and the corresponding syntax and semantics for
+ Routing Information are defined in other documents.
+
+ SRE Offset (1 octet)
+
+ The SRE Offset field indicates the octet offset from the start of the
+ Routing Information field to the first octet of the active entry in
+ Source Route Entry to be examined.
+
+ SRE Length (1 octet)
+
+ The SRE Length field contains the number of octets in the SRE. If
+ the SRE Length is 0, this indicates this is the last SRE in the
+ Routing field.
+
+ Routing Information (variable)
+
+ The Routing Information field contains data which may be used in
+ routing this packet. The exact semantics of this field is defined in
+ other documents.
+
+Forwarding of GRE packets
+
+ Normally, a system which is forwarding delivery layer packets will
+ not differentiate GRE packets from other packets in any way.
+ However, a GRE packet may be received by a system. In this case, the
+ system should use some delivery-specific means to determine that this
+ is a GRE packet. Once this is determined, the Key, Sequence Number
+ and Checksum fields if they contain valid information as indicated by
+ the corresponding flags may be checked. If the Routing Present bit
+
+
+
+Hanks, Li, Farinacci & Traina [Page 5]
+
+RFC 1701 Generic Routing Encapsulation (GRE) October 1994
+
+
+ is set to 1, then the Address Family field should be checked to
+ determine the semantics and use of the SRE Length, SRE Offset and
+ Routing Information fields. The exact semantics for processing a SRE
+ for each Address Family is defined in other documents.
+
+ Once all SREs have been processed, then the source route is complete,
+ the GRE header should be removed, the payload's TTL MUST be
+ decremented (if one exists) and the payload packet should be
+ forwarded as a normal packet. The exact forwarding method depends on
+ the Protocol Type field.
+
+Current List of Protocol Types
+
+ The following are currently assigned protocol types for GRE. Future
+ protocol types must be taken from DIX ethernet encoding. For
+ historical reasons, a number of other values have been used for some
+ protocols. The following table of values MUST be used to identify
+ the following protocols:
+
+ Protocol Family PTYPE
+ --------------- -----
+ Reserved 0000
+ SNA 0004
+ OSI network layer 00FE
+ PUP 0200
+ XNS 0600
+ IP 0800
+ Chaos 0804
+ RFC 826 ARP 0806
+ Frame Relay ARP 0808
+ VINES 0BAD
+ VINES Echo 0BAE
+ VINES Loopback 0BAF
+ DECnet (Phase IV) 6003
+ Transparent Ethernet Bridging 6558
+ Raw Frame Relay 6559
+ Apollo Domain 8019
+ Ethertalk (Appletalk) 809B
+ Novell IPX 8137
+ RFC 1144 TCP/IP compression 876B
+ IP Autonomous Systems 876C
+ Secure Data 876D
+ Reserved FFFF
+
+ See the IANA list of Ether Types for the complete list of these
+ values.
+
+ URL = ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers.
+
+
+
+Hanks, Li, Farinacci & Traina [Page 6]
+
+RFC 1701 Generic Routing Encapsulation (GRE) October 1994
+
+
+References
+
+ RFC 1479
+ Steenstrup, M. "Inter-Domain Policy Routing Protocol
+ Specification: Version 1", RFC1479, BBN Systems and Technologies,
+ July 1993.
+
+ RFC 1226
+ Kantor, B. "Internet Protocol Encapsulation of AX.25 Frames", RFC
+ 1226, University of California, San Diego, May 1991.
+
+ RFC 1234
+ Provan, D. "Tunneling IPX Traffic through IP Networks", RFC 1234,
+ Novell, Inc., June 1991.
+
+ RFC 1241
+ Woodburn, R., and D. Mills, "Scheme for an Internet Encapsulation
+ Protocol: Version 1", RFC 1241, SAIC, University of Delaware, July
+ 1991.
+
+ RFC 1326
+ Tsuchiya, P., "Mutual Encapsulation Considered Dangerous", RFC
+ 1326, Bellcore, May 1992.
+
+ SDRP
+ Estrin, D., Li, T., and Y. Rekhter, "Source Demand Routing
+ Protocol Specification (Version 1)", Work in Progress.
+
+ RFC 1702
+ Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing
+ Encapsulation over IPv4 networks", RFC 1702, NetSmiths, Ltd.,
+ cisco Systems, October 1994.
+
+Security Considerations
+
+ Security issues are not discussed in this memo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hanks, Li, Farinacci & Traina [Page 7]
+
+RFC 1701 Generic Routing Encapsulation (GRE) October 1994
+
+
+Acknowledgements
+
+ The authors would like to acknowledge Yakov Rekhter (IBM) and Deborah
+ Estrin (USC) for their advice, encouragement and insightful comments.
+
+Authors' Addresses
+
+ Stan Hanks
+ NetSmiths, Ltd.
+ 2025 Lincoln Highway
+ Edison NJ, 08817
+
+ EMail: stan@netsmiths.com
+
+
+ Tony Li
+ cisco Systems, Inc.
+ 1525 O'Brien Drive
+ Menlo Park, CA 94025
+
+ EMail: tli@cisco.com
+
+
+ Dino Farinacci
+ cisco Systems, Inc.
+ 1525 O'Brien Drive
+ Menlo Park, CA 94025
+
+ EMail: dino@cisco.com
+
+
+ Paul Traina
+ cisco Systems, Inc.
+ 1525 O'Brien Drive
+ Menlo Park, CA 94025
+
+ EMail: pst@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hanks, Li, Farinacci & Traina [Page 8]
+
diff --git a/rfc/rfc1702.txt b/rfc/rfc1702.txt
new file mode 100644
index 0000000..50b57ae
--- /dev/null
+++ b/rfc/rfc1702.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+Network Working Group S. Hanks
+Request for Comments: 1702 NetSmiths, Ltd.
+Category: Informational T. Li
+ D. Farinacci
+ P. Traina
+ cisco Systems
+ October 1994
+
+
+ Generic Routing Encapsulation over IPv4 networks
+
+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.
+
+Introduction
+
+ In an earlier memo [RFC 1701], we described GRE, a mechanism for
+ encapsulating arbitrary packets within an arbitrary transport
+ protocol. This is a companion memo which describes the use of GRE
+ with IP. This memo addresses the case of using IP as the delivery
+ protocol or the payload protocol and the special case of IP as both
+ the delivery and payload. This memo also describes using IP
+ addresses and autonomous system numbers as part of a GRE source
+ route.
+
+IP as a delivery protocol
+
+ GRE packets which are encapsulated within IP will use IP protocol
+ type 47.
+
+IP as a payload protocol
+
+ IP packets will be encapsulated with a Protocol Type field of 0x800.
+
+ For the Address Family value of 0x800, the Routing Information field
+ will consist of a list of IP addresses and indicates an IP source
+ route. The first octet of the Routing Information field constitute a
+ 8 bit integer offset from the start of the Source Route Entry (SRE),
+ called the SRE Offset. The SRE Offset indicates the first octet of
+ the next IP address. The SRE Length field consists of the total
+ length of the IP Address List in octets.
+
+
+
+
+
+
+
+Hanks, Li, Farinacci & Traina [Page 1]
+
+RFC 1702 GRE over IPv4 networks October 1994
+
+
+ This has the form:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Address Family | SRE Offset | SRE Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IP Address List ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ For the Address Family value of 0xfffe, the Routing Information field
+ will consist of a list of Autonomous System numbers and indicates an
+ AS source route. The third octet of the Routing Information field
+ contains an 8 bit unsigned integer offset from the start of the
+ Source Route Entry (SRE), called the SRE Offset. The SRE Offset
+ indicates the first octet of the next AS number. THe SRE Length
+ field consists of the total length of the AS Number list in octets.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Address Family | SRE Offset | SRE Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | AS Number List ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+IP as both delivery and payload protocol
+
+ When IP is encapsulated in IP, the TTL, TOS, and IP security options
+ MAY be copied from the payload packet into the same fields in the
+ delivery packet. The payload packet's TTL MUST be decremented when
+ the packet is decapsulated to insure that no packet lives forever.
+
+IP source routes
+
+ When a system is processing a SRE with an Address Family indicating
+ an IP source route, it MUST use the SRE Offset to determine the next
+ destination IP address. If the next IP destination is this system,
+ the SRE Offset field should be increased by four (the size of an IP
+ address). If the SRE Offset is equal to the SRE Length in this SRE,
+ then the Offset field in the GRE header should be adjusted to point
+ to the next SRE (if any). This should be repeated until the next IP
+ destination is not this system or until the entire SRE has been
+ processed.
+
+ If the source route is incomplete, then the Strict Source Route bit
+ is checked. If the source route is a strict source route and the
+ next IP destination is NOT an adjacent system, the packet MUST be
+
+
+
+Hanks, Li, Farinacci & Traina [Page 2]
+
+RFC 1702 GRE over IPv4 networks October 1994
+
+
+ dropped. Otherwise, the system should use the IP address indicated
+ by the Offset field to replace the destination address in the
+ delivery header and forward the packet.
+
+Autonomous system source routes
+
+ When a system is processing a SRE with an Address Family indicating
+ an AS source route, it MUST use the SRE Offset field to determine the
+ next autonomous system. If the next autonomous system is the local
+ autonomous system, the SRE Offset field should be increased by two
+ (the size of an autonomous system number). If the SRE Offset is
+ equal to the SRE Length in this SRE, then the Offset field in the GRE
+ header should be adjusted to point to the next SRE (if any). This
+ should be repeated until the next autonomous system number is not
+ equal to the local autonomous system number or until the entire SRE
+ has been processed.
+
+ If the source route is incomplete, then the Strict Source Route bit
+ is checked. If the source route is a strict source route and the
+ next autonomous system is NOT an adjacent autonomous system, the
+ packet should be dropped. Otherwise, the system should use the
+ autonomous system number indicated by the SRE Offset field to replace
+ the destination address in the delivery header and forward the
+ packet. The exact mechanism for determining the next delivery
+ destination address given the AS number is outside of the scope of
+ this document.
+
+Security Considerations
+
+ Security issues are not discussed in this memo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hanks, Li, Farinacci & Traina [Page 3]
+
+RFC 1702 GRE over IPv4 networks October 1994
+
+
+Authors' Addresses
+
+ Stan Hanks
+ NetSmiths, Ltd.
+ 2025 Lincoln Highway
+ Edison, NJ 08817
+
+ EMail: stan@netsmiths.com
+
+
+ Tony Li
+ cisco Systems, Inc.
+ 1525 O'Brien Drive
+ Menlo Park, CA 94025
+
+ EMail: tli@cisco.com
+
+
+ Dino Farinacci
+ cisco Systems, Inc.
+ 1525 O'Brien Drive
+ Menlo Park, CA 94025
+
+ EMail: dino@cisco.com
+
+
+ Paul Traina
+ cisco Systems, Inc.
+ 1525 O'Brien Drive
+ Menlo Park, CA 94025
+
+ EMail: pst@cisco.com
+
+References
+
+ RFC 1701
+ Hanks, S., Li, T, Farinacci, D., and P. Traina, "Generic Routing
+ Encapsulation", RFC 1701, NetSmiths, Ltd., and cisco Systems,
+ October 1994.
+
+
+
+
+
+
+
+
+
+
+
+
+Hanks, Li, Farinacci & Traina [Page 4]
+
diff --git a/rfc/rfc1877.txt b/rfc/rfc1877.txt
new file mode 100644
index 0000000..843c15c
--- /dev/null
+++ b/rfc/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/rfc/rfc1962.txt b/rfc/rfc1962.txt
new file mode 100644
index 0000000..fc9b47d
--- /dev/null
+++ b/rfc/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/rfc/rfc1979.txt b/rfc/rfc1979.txt
new file mode 100644
index 0000000..7a95cd3
--- /dev/null
+++ b/rfc/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/rfc/rfc1990.txt b/rfc/rfc1990.txt
new file mode 100644
index 0000000..a4f7ffe
--- /dev/null
+++ b/rfc/rfc1990.txt
@@ -0,0 +1,1347 @@
+
+
+
+
+
+
+Network Working Group K. Sklower
+Request for Comments: 1990 University of California, Berkeley
+Obsoletes: 1717 B. Lloyd
+Category: Standards Track G. McGregor
+ Lloyd Internetworking
+ D. Carr
+ Newbridge Networks Corporation
+ T. Coradetti
+ Sidewalk Software
+ August 1996
+
+
+ The PPP Multilink Protocol (MP)
+
+
+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
+
+ This document proposes a method for splitting, recombining and
+ sequencing datagrams across multiple logical data links. This work
+ was originally motivated by the desire to exploit multiple bearer
+ channels in ISDN, but is equally applicable to any situation in which
+ multiple PPP links connect two systems, including async links. This
+ is accomplished by means of new PPP [2] options and protocols.
+
+ The differences between the current PPP Multilink specification (RFC
+ 1717) and this memo are explained in Section 11. Any system
+ implementing the additional restrictions required by this memo will
+ be backwards compatible with conforming RFC 1717 implementations.
+
+Acknowledgements
+
+ The authors specifically wish to thank Fred Baker of ACC, Craig Fox
+ of Network Systems, Gerry Meyer of Spider Systems, Dan Brennan of
+ Penril Datability Networks, Vernon Schryver of SGI (for the
+ comprehensive discussion of padding), and the members of the IP over
+ Large Public Data Networks and PPP Extensions working groups, for
+ much useful discussion on the subject.
+
+
+
+
+
+
+Sklower, et. al. Standards Track [Page 1]
+
+RFC 1990 PPP Multilink August 1996
+
+
+Table of Contents
+
+ 1. Introduction ................................................ 2
+ 1.1. Motivation ................................................ 2
+ 1.2. Functional Description .................................... 3
+ 1.3. Conventions ............................................... 4
+ 2. General Overview ............................................ 4
+ 3. Packet Formats .............................................. 7
+ 3.1. Padding Considerations .................................... 10
+ 4. Trading Buffer Space Against Fragment Loss .................. 10
+ 4.1. Detecting Fragment Loss ................................... 11
+ 4.2. Buffer Space Requirements ................................. 12
+ 5. PPP Link Control Protocol Extensions ........................ 13
+ 5.1. Configuration Option Types ................................ 13
+ 5.1.1. Multilink MRRU LCP option ............................... 14
+ 5.1.2. Short Sequence Number Header Format Option .............. 15
+ 5.1.3. Endpoint Discriminator Option ........................... 15
+ 6. Initiating use of Multilink Headers ......................... 19
+ 7. Closing Member links ........................................ 20
+ 8. Interaction with Other Protocols ............................ 20
+ 9. Security Considerations ..................................... 21
+ 10. References ................................................. 21
+ 11. Differences from RFC 1717 .................................. 22
+ 11.1. Negotiating Multilink, per se ............................ 22
+ 11.2. Initial Sequence Number defined .......................... 22
+ 11.3. Default Value of the MRRU ................................ 22
+ 11.4. Config-Nak of EID prohibited ............................. 22
+ 11.5. Uniformity of Sequence Space ............................. 22
+ 11.6. Commencing and Abating use of Multilink Headers .......... 23
+ 11.7. Manual Configuration and Bundle Assignment ............... 23
+ 12. Authors' Addresses ......................................... 24
+
+1. Introduction
+
+1.1. Motivation
+
+ Basic Rate and Primary Rate ISDN both offer the possibility of
+ opening multiple simultaneous channels between systems, giving users
+ additional bandwidth on demand (for additional cost). Previous
+ proposals for the transmission of internet protocols over ISDN have
+ stated as a goal the ability to make use of this capability, (e.g.,
+ Leifer et al., [1]).
+
+ There are proposals being advanced for providing synchronization
+ between multiple streams at the bit level (the BONDING proposals);
+ such features are not as yet widely deployed, and may require
+ additional hardware for end system. Thus, it may be useful to have a
+ purely software solution, or at least an interim measure.
+
+
+
+Sklower, et. al. Standards Track [Page 2]
+
+RFC 1990 PPP Multilink August 1996
+
+
+ There are other instances where bandwidth on demand can be exploited,
+ such as using a dialup async line at 28,800 baud to back up a leased
+ synchronous line, or opening additional X.25 SVCs where the window
+ size is limited to two by international agreement.
+
+ The simplest possible algorithms of alternating packets between
+ channels on a space available basis (which might be called the Bank
+ Teller's algorithm) may have undesirable side effects due to
+ reordering of packets.
+
+ By means of a four-byte sequencing header, and simple synchronization
+ rules, one can split packets among parallel virtual circuits between
+ systems in such a way that packets do not become reordered, or at
+ least the likelihood of this is greatly reduced.
+
+1.2. Functional Description
+
+ The method discussed here is similar to the multilink protocol
+ described in ISO 7776 [4], but offers the additional ability to split
+ and recombine packets, thereby reducing latency, and potentially
+ increase the effective maximum receive unit (MRU). Furthermore,
+ there is no requirement here for acknowledged-mode operation on the
+ link layer, although that is optionally permitted.
+
+ Multilink is based on an LCP option negotiation that permits a system
+ to indicate to its peer that it is capable of combining multiple
+ physical links into a "bundle". Only under exceptional conditions
+ would a given pair of systems require the operation of more than one
+ bundle connecting them.
+
+ Multilink is negotiated during the initial LCP option negotiation. A
+ system indicates to its peer that it is willing to do multilink by
+ sending the multilink option as part of the initial LCP option
+ negotiation. This negotiation indicates three things:
+
+ 1. The system offering the option is capable of combining multiple
+ physical links into one logical link;
+
+ 2. The system is capable of receiving upper layer protocol data
+ units (PDU) fragmented using the multilink header (described
+ later) and reassembling the fragments back into the original PDU
+ for processing;
+
+ 3. The system is capable of receiving PDUs of size N octets where N
+ is specified as part of the option even if N is larger than the
+ maximum receive unit (MRU) for a single physical link.
+
+
+
+
+
+Sklower, et. al. Standards Track [Page 3]
+
+RFC 1990 PPP Multilink August 1996
+
+
+ Once multilink has been successfully negotiated, the sending system
+ is free to send PDUs encapsulated and/or fragmented with the
+ multilink header.
+
+1.3. Conventions
+
+ The following language conventions are used in the items of
+ specification in this document:
+
+ o MUST, SHALL or MANDATORY -- the item is an absolute requirement
+ of the specification.
+
+ o SHOULD or RECOMMENDED -- the item should generally be followed
+ for all but exceptional circumstances.
+
+ o MAY or OPTIONAL -- the item is truly optional and may be
+ followed or ignored according to the needs of the implementor.
+
+2. General 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 the data
+ link during Link Establishment phase. After the link has been
+ established, PPP provides for an Authentication phase in which the
+ authentication protocols can be used to determine identifiers
+ associated with each system connected by the link.
+
+ The goal of multilink operation is to coordinate multiple independent
+ links between a fixed pair of systems, providing a virtual link with
+ greater bandwidth than any of the constituent members. The aggregate
+ link, or bundle, is named by the pair of identifiers for two systems
+ connected by the multiple links. A system identifier may include
+ information provided by PPP Authentication [3] and information
+ provided by LCP negotiation. The bundled links can be different
+ physical links, as in multiple async lines, but may also be instances
+ of multiplexed links, such as ISDN, X.25 or Frame Relay. The links
+ may also be of different kinds, such as pairing dialup async links
+ with leased synchronous links.
+
+ We suggest that multilink operation can be modeled as a virtual PPP
+ link-layer entity wherein packets received over different physical
+ link-layer entities are identified as belonging to a separate PPP
+ network protocol (the Multilink Protocol, or MP) and recombined and
+ sequenced according to information present in a multilink
+ fragmentation header. All packets received over links identified as
+ belonging to the multilink arrangement are presented to the same
+ network-layer protocol processing machine, whether they have
+ multilink headers or not.
+
+
+
+Sklower, et. al. Standards Track [Page 4]
+
+RFC 1990 PPP Multilink August 1996
+
+
+ The packets to be transmitted using the multilink procedure are
+ encapsulated according to the rules for PPP where the following
+ options would have been manually configured:
+
+ o No async control character Map
+ o No Magic Number
+ o No Link Quality Monitoring
+ o Address and Control Field Compression
+ o Protocol Field Compression
+ o No Compound Frames
+ o No Self-Describing-Padding
+
+ According to the rules specified in RFC1661, this means that an
+ implementation MUST accept reassembled packets with and without
+ leading zeroes present in the Protocol Field of the reassembled
+ packet. Although it is explicitly forbidden below to include the
+ Address and Control fields (usually, the two bytes FF 03) in the
+ material to be fragmented, it is a good defensive programming
+ practice to accept the packet anyway, ignoring the two bytes if
+ present, as that is what RFC1661 specifies.
+
+ As a courtesy to implementations that perform better when certain
+ alignment obtains, it is suggested that a determination be made when
+ a bundle is created on whether to transmit leading zeroes by
+ examining whether PFC has been negotiated on the first link admitted
+ into a bundle. This determination should be kept in force so long as
+ a bundle persists.
+
+ Of course, individual links are permitted to have different settings
+ for these options. As described below, member links SHOULD negotiate
+ Self-Describing-Padding, even though pre-fragmented packets MUST NOT
+ be padded. Since the Protocol Field Compression mode on the member
+ link allows a sending system to include a leading byte of zero or not
+ at its discretion, this is an alternative mechanism for generating
+ even-length packets.
+
+ LCP negotiations are not permitted on the bundle itself. An
+ implementation MUST NOT transmit LCP Configure-Request, -Reject,
+ -Ack, -Nak, Terminate-Request or -Ack packets via the multilink
+ procedure, and an implementation receiving them MUST silently discard
+ them. (By "silently discard" we mean to not generate any PPP packets
+ in response; an implementation is free to generate a log entry
+ registering the reception of the unexpected packet). By contrast,
+ other LCP packets having control functions not associated with
+ changing the defaults for the bundle itself are permitted. An
+ implementation MAY transmit LCP Code-Reject, Protocol-Reject, Echo-
+ Request, Echo-Reply and Discard-Request Packets.
+
+
+
+
+Sklower, et. al. Standards Track [Page 5]
+
+RFC 1990 PPP Multilink August 1996
+
+
+ The effective MRU for the logical-link entity is negotiated via an
+ LCP option. It is irrelevant whether Network Control Protocol
+ packets are encapsulated in multilink headers or not, or even over
+ which link they are sent, once that link identifies itself as
+ belonging to a multilink arrangement.
+
+ Note that network protocols that are not sent using multilink headers
+ cannot be sequenced. (And consequently will be delivered in any
+ convenient way).
+
+ For example, consider the case in Figure 1. Link 1 has negotiated
+ network layers NL 1, NL 2, and MP between two systems. The two
+ systems then negotiate MP over Link 2.
+
+ Frames received on link 1 are demultiplexed at the data link layer
+ according the PPP network protocol identifier and can be sent to NL
+ 1, NL 2, or MP. Link 2 will accept frames with all network protocol
+ identifiers that Link 1 does.
+
+ Frames received by MP are further demultiplexed at the network layer
+ according to the PPP network protocol identifier and sent to NL 1 or
+ NL 2. Any frames received by MP for any other network layer
+ protocols are rejected using the normal protocol reject mechanism.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sklower, et. al. Standards Track [Page 6]
+
+RFC 1990 PPP Multilink August 1996
+
+
+ Figure 1. Multilink Overview.
+
+ Network Layer
+ -------------
+ ______ ______
+ / \ / \
+ | NL 1 | | NL 2 |
+ \______/ \______/
+ | | | | | |
+ | | +-------------o-o-o-+
+ | +------+ +-----+ | | |
+ | | | | | |
+ | +------o--o-------+ + |
+ | | |__|_ | |
+ | | / \ | |
+ | | | MLCP | <--- Link Layer
+ | | \______/ Demultiplexing
+ | | | | |
+ | | | | |
+ | | | <--- Virtual Link
+ | | | | |
+ | | | | |
+ | | | | |
+ | | + | |
+ ___|_| | ___|_|
+ / \ | / \
+ | LCP |------+-----| LCP | <--- Link Layer
+ \______/ \______/ Demultiplexing
+ | |
+ | |
+ Link 1 Link 2
+
+3. Packet Formats
+
+ In this section we describe the layout of individual fragments, which
+ are the "packets" in the Multilink Protocol. Network Protocol
+ packets are first encapsulated (but not framed) according to normal
+ PPP procedures, and large packets are broken up into multiple
+ segments sized appropriately for the multiple physical links.
+ Although it would otherwise be permitted by the PPP spec,
+ implementations MUST NOT include the Address and Control Field in the
+ logical entity to be fragmented. A new PPP header consisting of the
+ Multilink Protocol Identifier, and the Multilink header is inserted
+ before each section. (Thus the first fragment of a multilink packet
+ in PPP will have two headers, one for the fragment, followed by the
+ header for the packet itself).
+
+
+
+
+
+Sklower, et. al. Standards Track [Page 7]
+
+RFC 1990 PPP Multilink August 1996
+
+
+ Systems implementing the multilink procedure are not required to
+ fragment small packets. There is also no requirement that the
+ segments be of equal sizes, or that packets must be broken up at all.
+ A possible strategy for contending with member links of differing
+ transmission rates would be to divide the packets into segments
+ proportion to the transmission rates. Another strategy might be to
+ divide them into many equal fragments and distribute multiple
+ fragments per link, the numbers being proportional to the relative
+ speeds of the links.
+
+ PPP multilink fragments are encapsulated using the protocol
+ identifier 0x00-0x3d. Following the protocol identifier is a four
+ byte header containing a sequence number, and two one bit fields
+ indicating that the fragment begins a packet or terminates a packet.
+ After negotiation of an additional PPP LCP option, the four byte
+ header may be optionally replaced by a two byte header with only a 12
+ bit sequence space. Address & Control and Protocol ID compression
+ are assumed to be in effect. Individual fragments will, therefore,
+ have the following format:
+
+ Figure 2: Long Sequence Number Fragment Format.
+
+
+ +---------------+---------------+
+ PPP Header: | Address 0xff | Control 0x03 |
+ +---------------+---------------+
+ | PID(H) 0x00 | PID(L) 0x3d |
+ +-+-+-+-+-+-+-+-+---------------+
+ MP Header: |B|E|0|0|0|0|0|0|sequence number|
+ +-+-+-+-+-+-+-+-+---------------+
+ | sequence number (L) |
+ +---------------+---------------+
+ | fragment data |
+ | . |
+ | . |
+ | . |
+ +---------------+---------------+
+ PPP FCS: | FCS |
+ +---------------+---------------+
+
+
+
+
+
+
+
+
+
+
+
+
+Sklower, et. al. Standards Track [Page 8]
+
+RFC 1990 PPP Multilink August 1996
+
+
+ Figure 3: Short Sequence Number Fragment Format.
+
+
+ +---------------+---------------+
+ PPP Header: | Address 0xff | Control 0x03 |
+ +---------------+---------------+
+ | PID(H) 0x00 | PID(L) 0x3d |
+ +-+-+-+-+-------+---------------+
+ MP Header: |B|E|0|0| sequence number |
+ +-+-+-+-+-------+---------------+
+ | fragment data |
+ | . |
+ | . |
+ | . |
+ +---------------+---------------+
+ PPP FCS: | FCS |
+ +---------------+---------------+
+
+ The (B)eginning fragment bit is a one bit field set to 1 on the first
+ fragment derived from a PPP packet and set to 0 for all other
+ fragments from the same PPP packet.
+
+ The (E)nding fragment bit is a one bit field set to 1 on the last
+ fragment and set to 0 for all other fragments. A fragment may have
+ both the (B)eginning and (E)nding fragment bits set to 1.
+
+ The sequence field is a 24 bit or 12 bit number that is incremented
+ for every fragment transmitted. By default, the sequence field is 24
+ bits long, but can be negotiated to be only 12 bits with an LCP
+ configuration option described below.
+
+ Between the (E)nding fragment bit and the sequence number is a
+ reserved field, whose use is not currently defined, which MUST be set
+ to zero. It is 2 bits long when the use of short sequence numbers
+ has been negotiated, 6 bits otherwise.
+
+ In this multilink protocol, a single reassembly structure is
+ associated with the bundle. The multilink headers are interpreted in
+ the context of this structure.
+
+ The FCS field shown in the diagram is inherited from the normal
+ framing mechanism from the member link on which the packet is
+ transmitted. There is no separate FCS applied to the reconstituted
+ packet as a whole if transmitted in more than one fragment.
+
+
+
+
+
+
+
+Sklower, et. al. Standards Track [Page 9]
+
+RFC 1990 PPP Multilink August 1996
+
+
+3.1. Padding Considerations
+
+ Systems that support the multilink protocol SHOULD implement Self-
+ Describing-Padding. A system that implements self-describing-padding
+ by definition will either include the padding option in its initial
+ LCP Configure-Requests, or (to avoid the delay of a Configure-Reject)
+ include the padding option after receiving a NAK containing the
+ option.
+
+ A system that must pad its own transmissions but does not use Self-
+ Describing-Padding when not using multilink, MAY continue to not use
+ Self-Describing-Padding if it ensures by careful choice of fragment
+ lengths that only (E)nding fragments of packets are padded. A system
+ MUST NOT add padding to any packet that cannot be recognized as
+ padded by the peer. Non-terminal fragments MUST NOT be padded with
+ trailing material by any other method than Self-Describing-Padding.
+
+ A system MUST ensure that Self-Describing-Padding as described in RFC
+ 1570 [11] is negotiated on the individual link before transmitting
+ any multilink data packets if it might pad non-terminal fragments or
+ if it would use network or compression protocols that are vulnerable
+ to padding, as described in RFC 1570. If necessary, the system that
+ adds padding MUST use LCP Configure-NAK's to elicit a Configure-
+ Request for Self-Describing-Padding from the peer.
+
+ Note that LCP Configure-Requests can be sent at any time on any link,
+ and that the peer will always respond with a Configure-Request of its
+ own. A system that pads its transmissions but uses no protocols
+ other than multilink that are vulnerable to padding MAY delay
+ ensuring that the peer has Configure-Requested Self-Describing-
+ Padding until it seems desireable to negotiate the use of Multilink
+ itself. This permits the interoperability of a system that pads with
+ older peers that support neither Multilink nor Self-Describing-
+ Padding.
+
+4. Trading Buffer Space Against Fragment Loss
+
+ In a multilink procedure one channel may be delayed with respect to
+ the other channels in the bundle. This can lead to fragments being
+ received out of order, thus increasing the difficulty in detecting
+ the loss of a fragment. The task of estimating the amount of space
+ required for buffering on the receiver becomes more complex because
+ of this. In this section we discuss a technique for declaring that a
+ fragment is lost, with the intent of minimizing the buffer space
+ required, yet minimizing the number of avoidable packet losses.
+
+
+
+
+
+
+Sklower, et. al. Standards Track [Page 10]
+
+RFC 1990 PPP Multilink August 1996
+
+
+4.1. Detecting Fragment Loss
+
+ On each member link in a bundle, the sender MUST transmit fragments
+ with strictly increasing sequence numbers (modulo the size of the
+ sequence space). This requirement supports a strategy for the
+ receiver to detect lost fragments based on comparing sequence
+ numbers. The sequence number is not reset upon each new PPP packet,
+ and a sequence number is consumed even for those fragments which
+ contain an entire PPP packet, i.e., one in which both the (B)eginning
+ and (E)nding bits are set.
+
+ An implementation MUST set the sequence number of the first fragment
+ transmited on a newly-constructed bundle to zero. (Joining a
+ secondary link to an exisiting bundle is invisible to the protocol,
+ and an implementation MUST NOT reset the sequence number space in
+ this situation).
+
+ The receiver keeps track of the incoming sequence numbers on each
+ link in a bundle and maintains the current minimum of the most
+ recently received sequence number over all the member links in the
+ bundle (call this M). The receiver detects the end of a packet when
+ it receives a fragment bearing the (E)nding bit. Reassembly of the
+ packet is complete if all sequence numbers up to that fragment have
+ been received.
+
+ A lost fragment is detected when M advances past the sequence number
+ of a fragment bearing an (E)nding bit of a packet which has not been
+ completely reassembled (i.e., not all the sequence numbers between
+ the fragment bearing the (B)eginning bit and the fragment bearing the
+ (E)nding bit have been received). This is because of the increasing
+ sequence number rule over the bundle. Any sequence number so
+ detected is assumed to correspond to a fragment which has been lost.
+
+ An implementation MUST assume that if a fragment bears a (B)eginning
+ bit, that the previously numbered fragment bore an (E)nding bit.
+ Thus if a packet is lost bearing the (E)nding bit, and the packet
+ whose fragment number is M contains a (B)eginning bit, the
+ implementation MUST discard fragments for all unassembled packets
+ through M-1, but SHOULD NOT discard the fragment bearing the new
+ (B)eginning bit on this basis alone.
+
+ The detection of a lost fragment, whose sequence number was deduced
+ to be U, causes the receiver to discard all fragments up to the
+ lowest numbered fragment with an ending bit (possibly deduced)
+ greater than or equal to U. However, the quantity M may jump into
+ the middle of a chain of packets which can be successful completed.
+
+
+
+
+
+Sklower, et. al. Standards Track [Page 11]
+
+RFC 1990 PPP Multilink August 1996
+
+
+ Fragments may be lost due to corruption of individual packets or
+ catastrophic loss of the link (which may occur only in one
+ direction). This version of the multilink protocol mandates no
+ specific procedures for the detection of failed links. The PPP link
+ quality management facility, or the periodic issuance of LCP echo-
+ requests could be used to achieve this.
+
+ Senders SHOULD avoid keeping any member links idle to maximize early
+ detection of lost fragments by the receiver, since the value of M is
+ not incremented on idle links. Senders SHOULD rotate traffic among
+ the member links if there isn't sufficient traffic to overflow the
+ capacity of one link to avoid idle links.
+
+ Loss of the final fragment of a transmission can cause the receiver
+ to stall until new packets arrive. The likelihood of this may be
+ decreased by sending a null fragment on each member link in a bundle
+ that would otherwise become idle immediately after having transmitted
+ a fragment bearing the (E)nding bit, where a null fragment is one
+ consisting only of a multilink header bearing both the (B)egin and
+ (E)nding bits (i.e., having no payload). Implementations concerned
+ about either wasting bandwidth or per packet costs are not required
+ to send null fragments and may elect to defer sending them until a
+ timer expires, with the marginally increased possibility of lengthier
+ stalls in the receiver. The receiver SHOULD implement some type of
+ link idle timer to guard against indefinite stalls.
+
+ The increasing sequence per link rule prohibits the reallocation of
+ fragments queued up behind a failing link to a working one, a
+ practice which is not unusual for implementations of ISO multilink
+ over LAPB [4].
+
+4.2. Buffer Space Requirements
+
+ There is no amount of buffering that will guarantee correct detection
+ of fragment loss, since an adversarial peer may withhold a fragment
+ on one channel and send arbitrary amounts on the others. For the
+ usual case where all channels are transmitting, you can show that
+ there is a minimum amount below which you could not correctly detect
+ packet loss. The amount depends on the relative delay between the
+ channels, (D[channel-i,channel-j]), the data rate of each channel,
+ R[c], the maximum fragment size permitted on each channel, F[c], and
+ the total amount of buffering the transmitter has allocated amongst
+ the channels.
+
+ When using PPP, the delay between channels could be estimated by
+ using LCP echo request and echo reply packets. (In the case of links
+ of different transmission rates, the round trip times should be
+ adjusted to take this into account.) The slippage for each channel
+
+
+
+Sklower, et. al. Standards Track [Page 12]
+
+RFC 1990 PPP Multilink August 1996
+
+
+ is defined as the bandwidth times the delay for that channel relative
+ to the channel with the longest delay, S[c] = R[c] * D[c,c-worst].
+ (S[c-worst] will be zero, of course!)
+
+ A situation which would exacerbate sequence number skew would be one
+ in which there is extremely bursty traffic (almost allowing all
+ channels to drain), and then where the transmitter would first queue
+ up as many consecutively numbered packets on one link as it could,
+ then queue up the next batch on a second link, and so on. Since
+ transmitters must be able to buffer at least a maximum- sized
+ fragment for each link (and will usually buffer up at least two) A
+ receiver that allocates any less than S[1] + S[2] + ... + S[N] + F[1]
+ + ... + F[N], will be at risk for incorrectly assuming packet loss,
+ and therefore, SHOULD allocate at least twice that.
+
+5. PPP Link Control Protocol Extensions
+
+ If reliable multilink operation is desired, PPP Reliable Transmission
+ [6] (essentially the use of ISO LAPB) MUST be negotiated prior to the
+ use of the Multilink Protocol on each member link.
+
+ Whether or not reliable delivery is employed over member links, an
+ implementation MUST present a signal to the NCP's running over the
+ multilink arrangement that a loss has occurred.
+
+ Compression may be used separately on each member link, or run over
+ the bundle (as a logical group link). The use of multiple
+ compression streams under the bundle (i.e., on each link separately)
+ is indicated by running the Compression Control Protocol [5] but with
+ an alternative PPP protocol ID.
+
+5.1. Configuration Option Types
+
+ The Multilink Protocol introduces the use of additional LCP
+ Configuration Options:
+
+ o Multilink Maximum Received Reconstructed Unit
+ o Multilink Short Sequence Number Header Format
+ o Endpoint Discriminator
+
+
+
+
+
+
+
+
+
+
+
+
+Sklower, et. al. Standards Track [Page 13]
+
+RFC 1990 PPP Multilink August 1996
+
+
+5.1.1. Multilink MRRU LCP option
+
+ Figure 4: Multilink MRRU LCP option
+
+ 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 = 17 | Length = 4 | Max-Receive-Reconstructed-Unit|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The presence of this LCP option indicates that the system sending it
+ implements the PPP Multilink Protocol. If not rejected, the system
+ will construe all packets received on this link as being able to be
+ processed by a common protocol machine with any other packets
+ received from the same peer on any other link on which this option
+ has been accepted.
+
+ The Max-Receive-Reconstructed unit field is two octets, and specifies
+ the maximum number of octets in the Information fields of reassembled
+ packets. A system MUST be able to receive the full 1500 octet
+ Information field of any reassembled PPP packet although it MAY
+ attempt to negotiate a smaller, or larger value. The number 1500
+ here comes from the specification for the MRU LCP option in PPP; if
+ this requirement is changed in a future version of RFC 1661, the same
+ rules will apply here.
+
+ A system MUST include the LCP MRRU option in every LCP negotiation
+ intended to instantiate a bundle or to join an existing bundle. If
+ the LCP MRRU option is offered on a link which is intended to join an
+ existing bundle, a system MUST offer the same Max-Receive-
+ Reconstruct-Unit value previously negotiated for the bundle.
+
+ A system MUST NOT send any multilink packets on any link unless its
+ peer has offered the MMRU LCP option and the system has configure-
+ Ack'ed it during the most recent LCP negotiation on that link. A
+ system MAY include the MMRU LCP option in a configure-NAK, if its
+ peer has not offered it (until, according to PPP rules, the peer
+ configure-Reject's it).
+
+ Note: the MRRU value conveyed im this option corresponds to the MRU
+ of the bundle when conceptualized as a PPP entity; but the rules for
+ the Multilink MRRU option are different from the LCP MRU option, as
+ some value MUST be offered in every LCP negotiation, and that
+ confirmation of this option is required prior to multilink
+ interpretation.
+
+
+
+
+
+
+Sklower, et. al. Standards Track [Page 14]
+
+RFC 1990 PPP Multilink August 1996
+
+
+5.1.2. Short Sequence Number Header Format Option
+
+ Figure 5: Short Sequence Number Header Format Option
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type = 18 | Length = 2 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ This option advises the peer that the implementation wishes to
+ receive fragments with short, 12 bit sequence numbers. When a peer
+ system configure-Ack's this option, it MUST transmit all multilink
+ packets on all links of the bundle with 12 bit sequence numbers or
+ configure-Reject the option. If 12 bit sequence numbers are desired,
+ this option MUST be negotiated when the bundle is instantiated, and
+ MUST be explicitly included in every LCP configure request offered by
+ a system when the system intends to include that link in an existing
+ bundle using 12 bit sequence numbers. If this option is never
+ negotiated during the life of a bundle, sequence numbers are 24 bits
+ long.
+
+ An implementation wishing to transmit multilink fragments with short
+ sequence numbers MAY include the multilink short sequence number in a
+ configure-NAK to ask that the peer respond with a request to receive
+ short sequence numbers. The peer is not compelled to respond with
+ the option.
+
+5.1.3. Endpoint Discriminator Option
+
+ Figure 7: Endpoint Discriminator Option
+
+ 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 = 19 | Length | Class | Address ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The Endpoint Discriminator Option represents identification of the
+ system transmitting the packet. This option advises a system that
+ the peer on this link could be the same as the peer on another
+ existing link. If the option distinguishes this peer from all
+ others, a new bundle MUST be established from the link being
+ negotiated. If this option matches the class and address of some
+ other peer of an existing link, the new link MUST be joined to the
+ bundle containing the link to the matching peer or MUST establish a
+ new bundle, depending on the decision tree shown in (1) through (4)
+ below.
+
+
+
+Sklower, et. al. Standards Track [Page 15]
+
+RFC 1990 PPP Multilink August 1996
+
+
+ To securely join an existing bundle, a PPP authentication protocol
+ [3] must be used to obtain authenticated information from the peer to
+ prevent a hostile peer from joining an existing bundle by presenting
+ a falsified discriminator option.
+
+ This option is not required for multilink operation. If a system
+ does not receive the Multilink MRRU option, but does receive the
+ Endpoint Discriminator Option, and there is no manual configuration
+ providing outside information, the implementation MUST NOT assume
+ that multilink operation is being requested on this basis alone.
+
+ As there is also no requirement for authentication, there are four
+ sets of scenarios:
+
+ (1) No authentication, no discriminator:
+ All new links MUST be joined to one bundle, unless
+ there is manual configuration to the contrary.
+ It is also permissible to have more than one manually
+ configured bundle connecting two given systems.
+
+ (2) Discriminator, no authentication:
+ Discriminator match -> MUST join matching bundle,
+ discriminator mismatch -> MUST establish new bundle.
+
+ (3) No discriminator, authentication:
+ Authenticated match -> MUST join matching bundle,
+ authenticated mismatch -> MUST establish new bundle.
+
+ (4) Discriminator, authentication:
+ Discriminator match and authenticated match -> MUST join bundle,
+ discriminator mismatch -> MUST establish new bundle,
+ authenticated mismatch -> MUST establish new bundle.
+
+ The option contains a Class which selects an identifier address space
+ and an Address which selects a unique identifier within the class
+ address space.
+
+ This identifier is expected to refer to the mechanical equipment
+ associated with the transmitting system. For some classes,
+ uniqueness of the identifier is global and is not bounded by the
+ scope of a particular administrative domain. Within each class,
+ uniqueness of address values is controlled by a class dependent
+ policy for assigning values.
+
+ Each endpoint may chose an identifier class without restriction.
+ Since the objective is to detect mismatches between endpoints
+ erroneously assumed to be alike, mismatch on class alone is
+ sufficient. Although no one class is recommended, classes which have
+
+
+
+Sklower, et. al. Standards Track [Page 16]
+
+RFC 1990 PPP Multilink August 1996
+
+
+ universally unique values are preferred.
+
+ This option is not required to be supported either by the system or
+ the peer. If the option is not present in a Configure-Request, the
+ system MUST NOT generate a Configure-Nak of this option for any
+ reason; instead it SHOULD behave as if it had received the option
+ with Class = 0, Address = 0. If a system receives a Configure-Nak or
+ Configure-Reject of this option, it MUST remove it from any
+ additional Configure-Request.
+
+ The size is determined from the Length field of the element. For
+ some classes, the length is fixed, for others the length is variable.
+ The option is invalid if the Length field indicates a size below the
+ minimum for the class.
+
+ An implementation MAY use the Endpoint Discriminator to locate
+ administration or authentication records in a local database. Such
+ use of this option is incidental to its purpose and is deprecated
+ when a PPP Authentication protocol [3] can be used instead. Since
+ some classes permit the peer to generate random or locally assigned
+ address values, use of this option as a database key requires prior
+ agreement between peer administrators.
+
+ The specification of the subfields are:
+
+ Type
+ 19 = for Endpoint Discriminator
+
+ Length
+ 3 + length of Address
+
+ Class
+ The Class field is one octet and indicates the identifier
+ address space. The most up-to-date values of the LCP Endpoint
+ Discriminator Class field are specified in the most recent
+ "Assigned Numbers" RFC [7]. Current values are assigned as
+ follows:
+
+ 0 Null Class
+
+ 1 Locally Assigned Address
+
+ 2 Internet Protocol (IP) Address
+
+ 3 IEEE 802.1 Globally Assigned MAC Address
+
+ 4 PPP Magic-Number Block
+
+
+
+
+Sklower, et. al. Standards Track [Page 17]
+
+RFC 1990 PPP Multilink August 1996
+
+
+ 5 Public Switched Network Directory Number
+
+ Address
+ The Address field is one or more octets and indicates the
+ identifier address within the selected class. The length and
+ content depend on the value of the Class as follows:
+
+ Class 0 - Null Class
+
+ Maximum Length: 0
+
+ Content:
+ This class is the default value if the option is not
+ present in a received Configure-Request.
+
+ Class 1 - Locally Assigned Address
+
+ Maximum Length: 20
+
+ Content:
+
+ This class is defined to permit a local assignment in the
+ case where use of one of the globally unique classes is not
+ possible. Use of a device serial number is suggested. The
+ use of this class is deprecated since uniqueness is not
+ guaranteed.
+
+ Class 2 - Internet Protocol (IP) Address
+
+ Fixed Length: 4
+
+ Content:
+
+ An address in this class contains an IP host address as
+ defined in [8].
+
+ Class 3 - IEEE 802.1 Globally Assigned MAC Address
+
+ Fixed Length: 6
+
+ Content:
+
+ An address in this class contains an IEEE 802.1 MAC address
+ in canonical (802.3) format [9]. The address MUST have the
+ global/local assignment bit clear and MUST have the
+ multicast/specific bit clear. Locally assigned MAC
+ addresses should be represented using Class 1.
+
+
+
+
+Sklower, et. al. Standards Track [Page 18]
+
+RFC 1990 PPP Multilink August 1996
+
+
+ Class 4 - PPP Magic-Number Block
+
+ Maximum Length: 20
+
+ Content:
+
+ This is not an address but a block of 1 to 5 concatenated
+ 32 bit PPP Magic-Numbers as defined in [2]. This class
+ provides for automatic generation of a value likely but not
+ guaranteed to be unique. The same block MUST be used by an
+ endpoint continuously during any period in which at least
+ one link is in the LCP Open state. The use of this class
+ is deprecated.
+
+ Note that PPP Magic-Numbers are used in [2] to detect
+ unexpected loopbacks of a link from an endpoint to itself.
+ There is a small probability that two distinct endpoints
+ will generate matching magic-numbers. This probability is
+ geometrically reduced when the LCP negotiation is repeated
+ in search of the desired mismatch, if a peer can generate
+ uncorrelated magic-numbers.
+
+ As used here, magic-numbers are used to determine if two
+ links are in fact from the same peer endpoint or from two
+ distinct endpoints. The numbers always match when there is
+ one endpoint. There is a small probability that the
+ numbers will match even if there are two endpoints. To
+ achieve the same confidence that there is not a false match
+ as for LCP loopback detection, several uncorrelated magic-
+ numbers can be combined in one block.
+
+ Class 5 - Public Switched Network Directory Number
+
+ Maximum Length: 15
+
+ Content:
+
+ An address in this class contains an octet sequence as
+ defined by I.331 (E.164) representing an international
+ telephone directory number suitable for use to access the
+ endpoint via the public switched telephone network [10].
+
+6. Initiating use of Multilink Headers
+
+ When the use of the Multilink protocol has been negotiated on a link
+ (say Y), and the link is being added to a bundle which currently
+ contains a single existing link (say X), a system MUST transmit a
+ Multilink-encapsulated packet on X before transmitting any Multilink-
+
+
+
+Sklower, et. al. Standards Track [Page 19]
+
+RFC 1990 PPP Multilink August 1996
+
+
+ encapsulated packets on Y.
+
+ Since links may be added and removed from a bundle without destroying
+ the state associated with it, the fragment should be assigned the
+ appropriate (next) fragment number. As noted earlier, the first
+ fragment transmitted in the life of a bundle is assigned fragment
+ number 0.
+
+7. Closing Member links
+
+ Member links may be terminated according to normal PPP LCP procedures
+ using LCP Terminate-Request and Terminate-Ack packets on that member
+ link. Since it is assumed that member links usually do not reorder
+ packets, receipt of a terminate ack is sufficient to assume that any
+ multilink protocol packets ahead of it are at no special risk of
+ loss.
+
+ Receipt of an LCP Terminate-Request on one link does not conclude the
+ procedure on the remaining links.
+
+ So long as any member links in the bundle are active, the PPP state
+ for the bundle persists as a separate entity. However, if the there
+ is a unique link in the bundle, and all the other links were closed
+ gracefully (with Terminate-Ack), an implementation MAY cease using
+ multilink
+ headers.
+
+ If the multilink procedure is used in conjunction with PPP reliable
+ transmission, and a member link is not closed gracefully, the
+ implementation should expect to receive packets which violate the
+ increasing sequence number rule.
+
+8. Interaction with Other Protocols
+
+ In the common case, LCP, and the Authentication Control Protocol
+ would be negotiated over each member link. The Network Protocols
+ themselves and associated control exchanges would normally have been
+ conducted once, on the bundle.
+
+ In some instances it may be desirable for some Network Protocols to
+ be exempted from sequencing requirements, and if the MRU sizes of the
+ link did not cause fragmentation, those protocols could be sent
+ directly over the member links.
+
+ Although explicitly discouraged above, if there were several member
+ links connecting two implementations, and independent sequencing of
+ two protocol sets were desired, but blocking of one by the other was
+ not, one could describe two multilink procedures by assigning
+
+
+
+Sklower, et. al. Standards Track [Page 20]
+
+RFC 1990 PPP Multilink August 1996
+
+
+ multiple endpoint identifiers to a given system. Each member link,
+ however, would only belong to one bundle. One could think of a
+ physical router as housing two logically separate implementations,
+ each of which is independently configured.
+
+ A simpler solution would be to have one link refuse to join the
+ bundle, by sending a Configure-Reject in response to the Multilink
+ LCP option.
+
+9. Security Considerations
+
+ Operation of this protocol is no more and no less secure than
+ operation of the PPP authentication protocols [3]. The reader is
+ directed there for further discussion.
+
+10. References
+
+ [1] Leifer, D., Sheldon, S., and B. Gorsline, "A Subnetwork Control
+ Protocol for ISDN Circuit-Switching", University of Michigan
+ (unpublished), March 1991.
+
+ [2] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51,
+ RFC 1661, Daydreamer, July 1994.
+
+ [3] Lloyd, B., and W. Simpson, "PPP Authentication Protocols", RFC
+ 1334, Lloyd Internetworking, Daydreamer, October 1992.
+
+ [4] International Organisation for Standardization, "HDLC -
+ Description of the X.25 LAPB-Compatible DTE Data Link
+ Procedures", International Standard 7776, 1988
+
+ [5] Rand, D., "The PPP Compression Control Protocol (CCP)", PPP
+ Extensions Working Group, RFC 1962, June 1996.
+
+ [6] Rand, D., "PPP Reliable Transmission", RFC 1663, Novell, July
+ 1994
+
+ [7] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
+ USC/Information Sciences Institute, October 1994.
+
+ [8] Postel, J., Editor, "Internet Protocol - DARPA Internet Program
+ Protocol Specification", STD 5, RFC 791, USC/Information Sciences
+ Institute, September 1981.
+
+ [9] Institute of Electrical and Electronics Engineers, Inc., "IEEE
+ Local and Metropolitan Area Networks: Overview and Architecture",
+ IEEE Std. 802-1990, 1990.
+
+
+
+
+Sklower, et. al. Standards Track [Page 21]
+
+RFC 1990 PPP Multilink August 1996
+
+
+ [10] The International Telegraph and Telephone Consultative Committee
+ (CCITT), "Numbering Plan for the ISDN Area", Recommendation I.331
+ (E.164), 1988.
+
+ [11] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, Daydreamer,
+ January 1994.
+
+11. Differences from RFC 1717
+
+ This section documents differences from RFC 1717. There are
+ restrictions placed on implementations that were absent in RFC 1717;
+ systems obeying these restrictions are fully interoperable with RFC
+ 1717 - compliant systems.
+
+11.1. Negotiating Multilink, per se
+
+ RFC 1717 permitted either the use of the Short Sequence Number Header
+ Format (SSNHF) or the Maximum Reconstructed Receive Unit (MRRU)
+ options by themselves to indicate the intent to negotiate multilink.
+ This specification forbids the use of the SSNHF option by itself; but
+ does permit the specific of both options together. Any
+ implementation which otherwise conforms to rfc1717 and also obeys
+ this restriction will interoperate with any RFC 1717 implementation.
+
+11.2. Initial Sequence Number defined
+
+ This specification requires that the first sequence number
+ transmitted after the virtual link has reached to open state be 0.
+
+11.3. Default Value of the MRRU
+
+ This specfication removes the default value for the MRRU, (since it
+ must always be negotiated with some value), and specifies that an
+ implementation must be support an MRRU with same value as the default
+ MRU size for PPP.
+
+11.4. Config-Nak of EID prohibited
+
+ This specification forbids the config-Naking of an EID for any
+ reason.
+
+11.5. Uniformity of Sequence Space
+
+ This specification requires that the same sequence format be employed
+ on all links in a bundle.
+
+
+
+
+
+
+Sklower, et. al. Standards Track [Page 22]
+
+RFC 1990 PPP Multilink August 1996
+
+
+11.6. Commencing and Abating use of Multilink Headers
+
+ This memo specifies how one should start the use of Multilink Headers
+ when a link is added, and under what circumstances it is safe to
+ discontinue their use.
+
+11.7. Manual Configuration and Bundle Assignment
+
+ The document explicitly permits multiple bundles to be manually
+ configured in the absence of both the Endpoint Descriminator and any
+ form of authentication.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sklower, et. al. Standards Track [Page 23]
+
+RFC 1990 PPP Multilink August 1996
+
+
+13. Authors' Addresses
+
+ Keith Sklower
+ Computer Science Department
+ 384 Soda Hall, Mail Stop 1776
+ University of California
+ Berkeley, CA 94720-1776
+
+ Phone: (510) 642-9587
+ EMail: sklower@CS.Berkeley.EDU
+
+
+ Brian Lloyd
+ Lloyd Internetworking
+ 3031 Alhambra Drive
+ Cameron Park, CA 95682
+
+ Phone: (916) 676-1147
+ EMail: brian@lloyd.com
+
+
+ Glenn McGregor
+ Lloyd Internetworking
+ 3031 Alhambra Drive
+ Cameron Park, CA 95682
+
+ Phone: (916) 676-1147
+ EMail: glenn@lloyd.com
+
+
+ Dave Carr
+ Newbridge Networks Corporation
+ 600 March Road
+ P.O. Box 13600
+ Kanata, Ontario,
+ Canada, K2K 2E6
+
+ Phone: (613) 591-3600
+ EMail: dcarr@Newbridge.COM
+
+
+ Tom Coradetti
+ Sidewalk Software
+ 1190 Josephine Road
+ Roseville, MN 55113
+
+ Phone: (612) 490 7856
+ EMail: 70761.1664@compuserve.com
+
+
+
+Sklower, et. al. Standards Track [Page 24]
+
diff --git a/rfc/rfc1994.txt b/rfc/rfc1994.txt
new file mode 100644
index 0000000..e4a553e
--- /dev/null
+++ b/rfc/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/rfc/rfc2138.txt b/rfc/rfc2138.txt
new file mode 100644
index 0000000..9f4a86d
--- /dev/null
+++ b/rfc/rfc2138.txt
@@ -0,0 +1,3643 @@
+
+
+
+
+
+
+Network Working Group C. Rigney
+Request for Comments: 2138 Livingston
+Obsoletes: 2058 A. Rubens
+Category: Standards Track Merit
+ W. Simpson
+ Daydreamer
+ S. Willens
+ Livingston
+ April 1997
+
+
+ Remote Authentication Dial In User Service (RADIUS)
+
+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
+
+ This document describes a protocol for carrying authentication,
+ authorization, and configuration information between a Network Access
+ Server which desires to authenticate its links and a shared
+ Authentication Server.
+
+Implementation Note
+
+ This memo documents the RADIUS protocol. There has been some
+ confusion in the assignment of port numbers for this protocol. The
+ early deployment of RADIUS was done using the erroneously chosen port
+ number 1645, which conflicts with the "datametrics" service. The
+ officially assigned port number for RADIUS is 1812.
+
+Table of Contents
+
+ 1. Introduction .......................................... 3
+ 1.1 Specification of Requirements ................... 4
+ 1.2 Terminology ..................................... 5
+ 2. Operation ............................................. 5
+ 2.1 Challenge/Response .............................. 7
+ 2.2 Interoperation with PAP and CHAP ................ 7
+ 2.3 Why UDP? ........................................ 8
+ 3. Packet Format ......................................... 10
+ 4. Packet Types .......................................... 13
+ 4.1 Access-Request .................................. 13
+
+
+
+Rigney, et. al. Standards Track [Page 1]
+
+RFC 2138 RADIUS April 1997
+
+
+ 4.2 Access-Accept ................................... 14
+ 4.3 Access-Reject ................................... 15
+ 4.4 Access-Challenge ................................ 17
+ 5. Attributes ............................................ 18
+ 5.1 User-Name ....................................... 21
+ 5.2 User-Password ................................... 22
+ 5.3 CHAP-Password ................................... 23
+ 5.4 NAS-IP-Address .................................. 24
+ 5.5 NAS-Port ........................................ 25
+ 5.6 Service-Type .................................... 26
+ 5.7 Framed-Protocol ................................. 28
+ 5.8 Framed-IP-Address ............................... 29
+ 5.9 Framed-IP-Netmask ............................... 29
+ 5.10 Framed-Routing .................................. 30
+ 5.11 Filter-Id ....................................... 31
+ 5.12 Framed-MTU ...................................... 32
+ 5.13 Framed-Compression .............................. 33
+ 5.14 Login-IP-Host ................................... 33
+ 5.15 Login-Service ................................... 34
+ 5.16 Login-TCP-Port .................................. 35
+ 5.17 (unassigned) .................................... 36
+ 5.18 Reply-Message ................................... 36
+ 5.19 Callback-Number ................................. 37
+ 5.20 Callback-Id ..................................... 38
+ 5.21 (unassigned) .................................... 38
+ 5.22 Framed-Route .................................... 39
+ 5.23 Framed-IPX-Network .............................. 40
+ 5.24 State ........................................... 40
+ 5.25 Class ........................................... 41
+ 5.26 Vendor-Specific ................................. 42
+ 5.27 Session-Timeout ................................. 44
+ 5.28 Idle-Timeout .................................... 44
+ 5.29 Termination-Action .............................. 45
+ 5.30 Called-Station-Id ............................... 46
+ 5.31 Calling-Station-Id .............................. 47
+ 5.32 NAS-Identifier .................................. 48
+ 5.33 Proxy-State ..................................... 48
+ 5.34 Login-LAT-Service ............................... 49
+ 5.35 Login-LAT-Node .................................. 50
+ 5.36 Login-LAT-Group ................................. 51
+ 5.37 Framed-AppleTalk-Link ........................... 52
+ 5.38 Framed-AppleTalk-Network ........................ 53
+ 5.39 Framed-AppleTalk-Zone ........................... 54
+ 5.40 CHAP-Challenge .................................. 55
+ 5.41 NAS-Port-Type ................................... 55
+ 5.42 Port-Limit ...................................... 56
+ 5.43 Login-LAT-Port .................................. 57
+ 5.44 Table of Attributes ............................. 58
+
+
+
+Rigney, et. al. Standards Track [Page 2]
+
+RFC 2138 RADIUS April 1997
+
+
+ 6. Examples .............................................. 59
+ 6.1 User Telnet to Specified Host ................... 60
+ 6.2 Framed User Authenticating with CHAP ............ 60
+ 6.3 User with Challenge-Response card ............... 61
+ Security Considerations ...................................... 63
+ References ................................................... 64
+ Acknowledgements ............................................. 64
+ Chair's Address .............................................. 65
+ Author's Addresses ........................................... 65
+
+1. Introduction
+
+ Managing dispersed serial line and modem pools for large numbers of
+ users can create the need for significant administrative support.
+ Since modem pools are by definition a link to the outside world, they
+ require careful attention to security, authorization and accounting.
+ This can be best achieved by managing a single "database" of users,
+ which allows for authentication (verifying user name and password) as
+ well as configuration information detailing the type of service to
+ deliver to the user (for example, SLIP, PPP, telnet, rlogin).
+
+ Key features of RADIUS are:
+
+ Client/Server Model
+
+ A Network Access Server (NAS) operates as a client of RADIUS. The
+ client is responsible for passing user information to designated
+ RADIUS servers, and then acting on the response which is returned.
+
+ RADIUS servers are responsible for receiving user connection
+ requests, authenticating the user, and then returning all
+ configuration information necessary for the client to deliver
+ service to the user.
+
+ A RADIUS server can act as a proxy client to other RADIUS servers
+ or other kinds of authentication servers.
+
+ Network Security
+
+ Transactions between the client and RADIUS server are
+ authenticated through the use of a shared secret, which is never
+ sent over the network. In addition, any user passwords are sent
+ encrypted between the client and RADIUS server, to eliminate the
+ possibility that someone snooping on an unsecure network could
+ determine a user's password.
+
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 3]
+
+RFC 2138 RADIUS April 1997
+
+
+ Flexible Authentication Mechanisms
+
+ The RADIUS server can support a variety of methods to authenticate
+ a user. When it is provided with the user name and original
+ password given by the user, it can support PPP PAP or CHAP, UNIX
+ login, and other authentication mechanisms.
+
+ Extensible Protocol
+
+ All transactions are comprised of variable length Attribute-
+ Length-Value 3-tuples. New attribute values can be added without
+ disturbing existing implementations of the protocol.
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 4]
+
+RFC 2138 RADIUS April 1997
+
+
+1.2. Terminology
+
+ This document frequently uses the following terms:
+
+ service The NAS provides a service to the dial-in user, such as PPP
+ or Telnet.
+
+ session Each service provided by the NAS to a dial-in user
+ constitutes a session, with the beginning of the session
+ defined as the point where service is first provided and
+ the end of the session defined as the point where service
+ is ended. A user may have multiple sessions in parallel or
+ series if the NAS supports that.
+
+ 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. Operation
+
+ When a client is configured to use RADIUS, any user of the client
+ presents authentication information to the client. This might be
+ with a customizable login prompt, where the user is expected to enter
+ their username and password. Alternatively, the user might use a
+ link framing protocol such as the Point-to-Point Protocol (PPP),
+ which has authentication packets which carry this information.
+
+ Once the client has obtained such information, it may choose to
+ authenticate using RADIUS. To do so, the client creates an "Access-
+ Request" containing such Attributes as the user's name, the user's
+ password, the ID of the client and the Port ID which the user is
+ accessing. When a password is present, it is hidden using a method
+ based on the RSA Message Digest Algorithm MD5 [1].
+
+ The Access-Request is submitted to the RADIUS server via the network.
+ If no response is returned within a length of time, the request is
+ re-sent a number of times. The client can also forward requests to
+ an alternate server or servers in the event that the primary server
+ is down or unreachable. An alternate server can be used either after
+ a number of tries to the primary server fail, or in a round-robin
+ fashion. Retry and fallback algorithms are the topic of current
+ research and are not specified in detail in this document.
+
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 5]
+
+RFC 2138 RADIUS April 1997
+
+
+ Once the RADIUS server receives the request, it validates the sending
+ client. A request from a client for which the RADIUS server does not
+ have a shared secret should be silently discarded. If the client is
+ valid, the RADIUS server consults a database of users to find the
+ user whose name matches the request. The user entry in the database
+ contains a list of requirements which must be met to allow access for
+ the user. This always includes verification of the password, but can
+ also specify the client(s) or port(s) to which the user is allowed
+ access.
+
+ The RADIUS server MAY make requests of other servers in order to
+ satisfy the request, in which case it acts as a client.
+
+ If any condition is not met, the RADIUS server sends an "Access-
+ Reject" response indicating that this user request is invalid. If
+ desired, the server MAY include a text message in the Access-Reject
+ which MAY be displayed by the client to the user. No other
+ Attributes are permitted in an Access-Reject.
+
+ If all conditions are met and the RADIUS server wishes to issue a
+ challenge to which the user must respond, the RADIUS server sends an
+ "Access-Challenge" response. It MAY include a text message to be
+ displayed by the client to the user prompting for a response to the
+ challenge, and MAY include a State attribute. If the client receives
+ an Access-Challenge and supports challenge/response it MAY display
+ the text message, if any, to the user, and then prompt the user for a
+ response. The client then re-submits its original Access-Request
+ with a new request ID, with the User-Password Attribute replaced by
+ the response (encrypted), and including the State Attribute from the
+ Access-Challenge, if any. Only 0 or 1 instances of the State
+ Attributes should be present in a request. The server can respond to
+ this new Access-Request with either an Access-Accept, an Access-
+ Reject, or another Access-Challenge.
+
+ If all conditions are met, the list of configuration values for the
+ user are placed into an "Access-Accept" response. These values
+ include the type of service (for example: SLIP, PPP, Login User) and
+ all necessary values to deliver the desired service. For SLIP and
+ PPP, this may include values such as IP address, subnet mask, MTU,
+ desired compression, and desired packet filter identifiers. For
+ character mode users, this may include values such as desired
+ protocol and host.
+
+
+
+
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 6]
+
+RFC 2138 RADIUS April 1997
+
+
+2.1. Challenge/Response
+
+ In challenge/response authentication, the user is given an
+ unpredictable number and challenged to encrypt it and give back the
+ result. Authorized users are equipped with special devices such as
+ smart cards or software that facilitate calculation of the correct
+ response with ease. Unauthorized users, lacking the appropriate
+ device or software and lacking knowledge of the secret key necessary
+ to emulate such a device or software, can only guess at the response.
+
+ The Access-Challenge packet typically contains a Reply-Message
+ including a challenge to be displayed to the user, such as a numeric
+ value unlikely ever to be repeated. Typically this is obtained from
+ an external server that knows what type of authenticator should be in
+ the possession of the authorized user and can therefore choose a
+ random or non-repeating pseudorandom number of an appropriate radix
+ and length.
+
+ The user then enters the challenge into his device (or software) and
+ it calculates a response, which the user enters into the client which
+ forwards it to the RADIUS server via a second Access-Request. If the
+ response matches the expected response the RADIUS server replies with
+ an Access-Accept, otherwise an Access-Reject.
+
+ Example: The NAS sends an Access-Request packet to the RADIUS Server
+ with NAS-Identifier, NAS-Port, User-Name, User-Password (which may
+ just be a fixed string like "challenge" or ignored). The server
+ sends back an Access-Challenge packet with State and a Reply-Message
+ along the lines of "Challenge 12345678, enter your response at the
+ prompt" which the NAS displays. The NAS prompts for the response and
+ sends a NEW Access-Request to the server (with a new ID) with NAS-
+ Identifier, NAS-Port, User-Name, User-Password (the response just
+ entered by the user, encrypted), and the same State Attribute that
+ came with the Access-Challenge. The server then sends back either an
+ Access-Accept or Access-Reject based on whether the response matches
+ what it should be, or it can even send another Access-Challenge.
+
+2.2. Interoperation with PAP and CHAP
+
+ For PAP, the NAS takes the PAP ID and password and sends them in an
+ Access-Request packet as the User-Name and User-Password. The NAS MAY
+ include the Attributes Service-Type = Framed-User and Framed-Protocol
+ = PPP as a hint to the RADIUS server that PPP service is expected.
+
+ For CHAP, the NAS generates a random challenge (preferably 16 octets)
+ and sends it to the user, who returns a CHAP response along with a
+ CHAP ID and CHAP username. The NAS then sends an Access-Request
+ packet to the RADIUS server with the CHAP username as the User-Name
+
+
+
+Rigney, et. al. Standards Track [Page 7]
+
+RFC 2138 RADIUS April 1997
+
+
+ and with the CHAP ID and CHAP response as the CHAP-Password
+ (Attribute 3). The random challenge can either be included in the
+ CHAP-Challenge attribute or, if it is 16 octets long, it can be
+ placed in the Request Authenticator field of the Access-Request
+ packet. The NAS MAY include the Attributes Service-Type = Framed-
+ User and Framed-Protocol = PPP as a hint to the RADIUS server that
+ PPP service is expected.
+
+ The RADIUS server looks up a password based on the User-Name,
+ encrypts the challenge using MD5 on the CHAP ID octet, that password,
+ and the CHAP challenge (from the CHAP-Challenge attribute if present,
+ otherwise from the Request Authenticator), and compares that result
+ to the CHAP-Password. If they match, the server sends back an
+ Access-Accept, otherwise it sends back an Access-Reject.
+
+ If the RADIUS server is unable to perform the requested
+ authentication it should return an Access-Reject. For example, CHAP
+ requires that the user's password be available in cleartext to the
+ server so that it can encrypt the CHAP challenge and compare that to
+ the CHAP response. If the password is not available in cleartext to
+ the RADIUS server then the server MUST send an Access-Reject to the
+ client.
+
+2.3. Why UDP?
+
+ A frequently asked question is why RADIUS uses UDP instead of TCP as
+ a transport protocol. UDP was chosen for strictly technical reasons.
+
+ There are a number of issues which must be understood. RADIUS is a
+ transaction based protocol which has several interesting
+ characteristics:
+
+ 1. If the request to a primary Authentication server fails, a
+ secondary server must be queried.
+
+ To meet this requirement, a copy of the request must be kept
+ above the transport layer to allow for alternate transmission.
+ This means that retransmission timers are still required.
+
+ 2. The timing requirements of this particular protocol are
+ significantly different than TCP provides.
+
+ At one extreme, RADIUS does not require a "responsive"
+ detection of lost data. The user is willing to wait several
+ seconds for the authentication to complete. The generally
+ aggressive TCP retransmission (based on average round trip
+ time) is not required, nor is the acknowledgement overhead of
+ TCP.
+
+
+
+Rigney, et. al. Standards Track [Page 8]
+
+RFC 2138 RADIUS April 1997
+
+
+ At the other extreme, the user is not willing to wait several
+ minutes for authentication. Therefore the reliable delivery of
+ TCP data two minutes later is not useful. The faster use of an
+ alternate server allows the user to gain access before giving
+ up.
+
+ 3. The stateless nature of this protocol simplifies the use of UDP.
+
+ Clients and servers come and go. Systems are rebooted, or are
+ power cycled independently. Generally this does not cause a
+ problem and with creative timeouts and detection of lost TCP
+ connections, code can be written to handle anomalous events.
+ UDP however completely eliminates any of this special handling.
+ Each client and server can open their UDP transport just once
+ and leave it open through all types of failure events on the
+ network.
+
+ 4. UDP simplifies the server implementation.
+
+ In the earliest implementations of RADIUS, the server was
+ single threaded. This means that a single request was
+ received, processed, and returned. This was found to be
+ unmanageable in environments where the back-end security
+ mechanism took real time (1 or more seconds). The server
+ request queue would fill and in environments where hundreds of
+ people were being authenticated every minute, the request
+ turn-around time increased to longer that users were willing to
+ wait (this was especially severe when a specific lookup in a
+ database or over DNS took 30 or more seconds). The obvious
+ solution was to make the server multi-threaded. Achieving this
+ was simple with UDP. Separate processes were spawned to serve
+ each request and these processes could respond directly to the
+ client NAS with a simple UDP packet to the original transport
+ of the client.
+
+ It's not all a panacea. As noted, using UDP requires one thing
+ which is built into TCP: with UDP we must artificially manage
+ retransmission timers to the same server, although they don't
+ require the same attention to timing provided by TCP. This one
+ penalty is a small price to pay for the advantages of UDP in
+ this protocol.
+
+ Without TCP we would still probably be using tin cans connected
+ by string. But for this particular protocol, UDP is a better
+ choice.
+
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 9]
+
+RFC 2138 RADIUS April 1997
+
+
+3. Packet Format
+
+ Exactly one RADIUS packet is encapsulated in the UDP Data field [2],
+ where the UDP Destination Port field indicates 1812 (decimal).
+
+ When a reply is generated, the source and destination ports are
+ reversed.
+
+ This memo documents the RADIUS protocol. There has been some
+ confusion in the assignment of port numbers for this protocol. The
+ early deployment of RADIUS was done using the erroneously chosen port
+ number 1645, which conflicts with the "datametrics" service. The
+ officially assigned port number for RADIUS is 1812.
+
+ A summary of the RADIUS data 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ | Authenticator |
+ | |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Attributes ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-
+
+Code
+
+ The Code field is one octet, and identifies the type of RADIUS
+ packet. When a packet is received with an invalid Code field, it is
+ silently discarded.
+
+ RADIUS Codes (decimal) are assigned as follows:
+
+ 1 Access-Request
+ 2 Access-Accept
+ 3 Access-Reject
+ 4 Accounting-Request
+ 5 Accounting-Response
+ 11 Access-Challenge
+ 12 Status-Server (experimental)
+ 13 Status-Client (experimental)
+ 255 Reserved
+
+
+
+
+Rigney, et. al. Standards Track [Page 10]
+
+RFC 2138 RADIUS April 1997
+
+
+ Codes 4 and 5 are covered in the RADIUS Accounting document [9], and
+ are not further mentioned here. Codes 12 and 13 are reserved for
+ possible use, but are not further mentioned here.
+
+Identifier
+
+ The Identifier field is one octet, and aids in matching requests and
+ replies.
+
+Length
+
+ The Length field is two octets. It indicates the length of the
+ packet including the Code, Identifier, Length, Authenticator and
+ Attribute fields. Octets outside the range of the Length field
+ should be treated as padding and should be ignored on reception. If
+ the packet is shorter than the Length field indicates, it should be
+ silently discarded. The minimum length is 20 and maximum length is
+ 4096.
+
+Authenticator
+
+ The Authenticator field is sixteen (16) octets. The most significant
+ octet is transmitted first. This value is used to authenticate the
+ reply from the RADIUS server, and is used in the password hiding
+ algorithm.
+
+Request Authenticator
+
+ In Access-Request Packets, the Authenticator value is a 16 octet
+ random number, called the Request Authenticator. The value SHOULD
+ be unpredictable and unique over the lifetime of a secret (the
+ password shared between the client and the RADIUS server), since
+ repetition of a request 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
+ Request Authenticator field SHOULD exhibit global and temporal
+ uniqueness.
+
+ The Request Authenticator value in an Access-Request packet SHOULD
+ also be unpredictable, lest an attacker trick a server into
+ responding to a predicted future request, and then use the
+ response to masquerade as that server to a future Access-Request.
+
+
+
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 11]
+
+RFC 2138 RADIUS April 1997
+
+
+ Although protocols such as RADIUS are incapable of protecting
+ against theft of an authenticated session via realtime active
+ wiretapping attacks, generation of unique unpredictable requests
+ can protect against a wide range of active attacks against
+ authentication.
+
+ The NAS and RADIUS server share a secret. That shared secret
+ followed by the Request Authenticator is put through a one-way MD5
+ hash to create a 16 octet digest value which is xored with the
+ password entered by the user, and the xored result placed in the
+ User-Password attribute in the Access-Request packet. See the
+ entry for User-Password in the section on Attributes for a more
+ detailed description.
+
+ Response Authenticator
+
+ The value of the Authenticator field in Access-Accept, Access-
+ Reject, and Access-Challenge packets is called the Response
+ Authenticator, and contains a one-way MD5 hash calculated over a
+ stream of octets consisting of: the RADIUS packet, beginning with
+ the Code field, including the Identifier, the Length, the Request
+ Authenticator field from the Access-Request packet, and the
+ response Attributes, followed by the shared secret. That is,
+ ResponseAuth = MD5(Code+ID+Length+RequestAuth+Attributes+Secret)
+ where + denotes concatenation.
+
+Administrative Note
+
+ The secret (password shared between the client and the RADIUS server)
+ SHOULD be at least as large and unguessable as a well-chosen
+ password. It is preferred that the secret be at least 16 octets.
+ This is to ensure a sufficiently large range for the secret to
+ provide protection against exhaustive search attacks. A RADIUS
+ server SHOULD use the source IP address of the RADIUS UDP packet to
+ decide which shared secret to use, so that RADIUS requests can be
+ proxied.
+
+ When using a forwarding proxy, the proxy must be able to alter the
+ packet as it passes through in each direction - when the proxy
+ forwards the request, the proxy can add a Proxy-State Attribute, and
+ when the proxy forwards a response, it removes the Proxy-State
+ Attribute. Since Access-Accept and Access-Reject replies are
+ authenticated on the entire packet contents, the stripping of the
+ Proxy-State attribute would invalidate the signature in the packet -
+ so the proxy has to re-sign it.
+
+ Further details of RADIUS proxy implementation are outside the scope
+ of this document.
+
+
+
+Rigney, et. al. Standards Track [Page 12]
+
+RFC 2138 RADIUS April 1997
+
+
+Attributes
+
+ Many Attributes may have multiple instances, in such a case the order
+ of Attributes of the same Type SHOULD be preserved. The order of
+ Attributes of different Types is not required to be preserved.
+
+ In the section below on "Attributes" where the text refers to which
+ packets an attribute is allowed in, only packets with Codes 1, 2, 3
+ and 11 and attributes defined in this document are covered in this
+ document. A summary table is provided at the end of the "Attributes"
+ section. To determine which Attributes are allowed in packets with
+ codes 4 and 5 refer to the RADIUS Accounting document [9].
+
+4. Packet Types
+
+ The RADIUS Packet type is determined by the Code field in the first
+ octet of the Packet.
+
+4.1. Access-Request
+
+ Description
+
+ Access-Request packets are sent to a RADIUS server, and convey
+ information used to determine whether a user is allowed access to
+ a specific NAS, and any special services requested for that user.
+ An implementation wishing to authenticate a user MUST transmit a
+ RADIUS packet with the Code field set to 1 (Access-Request).
+
+ Upon receipt of an Access-Request from a valid client, an
+ appropriate reply MUST be transmitted.
+
+ An Access-Request MUST contain a User-Name attribute. It SHOULD
+ contain either a NAS-IP-Address attribute or NAS-Identifier
+ attribute (or both, although that is not recommended). It MUST
+ contain either a User-Password attribute or CHAP-Password
+ attribute. It SHOULD contain a NAS-Port or NAS-Port-Type
+ attribute or both unless the type of access being requested does
+ not involve a port or the NAS does not distinguish among its
+ ports.
+
+ An Access-Request MAY contain additional attributes as a hint to
+ the server, but the server is not required to honor the hint.
+
+ When a User-Password is present, it is hidden using a method based
+ on the RSA Message Digest Algorithm MD5 [1].
+
+ A summary of the Access-Request packet format is shown below. The
+ fields are transmitted from left to right.
+
+
+
+Rigney, et. al. Standards Track [Page 13]
+
+RFC 2138 RADIUS April 1997
+
+
+ 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ | Request Authenticator |
+ | |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Attributes ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Code
+
+ 1 for Access-Request.
+
+ Identifier
+
+ The Identifier field MUST be changed whenever the content of the
+ Attributes field changes, and whenever a valid reply has been
+ received for a previous request. For retransmissions, the
+ Identifier MUST remain unchanged.
+
+ Request Authenticator
+
+ The Request Authenticator value MUST be changed each time a new
+ Identifier is used.
+
+ Attributes
+
+ The Attribute field is variable in length, and contains the list
+ of Attributes that are required for the type of service, as well
+ as any desired optional Attributes.
+
+4.2. Access-Accept
+
+ Description
+
+ Access-Accept packets are sent by the RADIUS server, and provide
+ specific configuration information necessary to begin delivery of
+ service to the user. If all Attribute values received in an
+ Access-Request are acceptable then the RADIUS implementation MUST
+ transmit a packet with the Code field set to 2 (Access-Accept).
+
+
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 14]
+
+RFC 2138 RADIUS April 1997
+
+
+ On reception of an Access-Accept, the Identifier field is matched
+ with a pending Access-Request. Additionally, the Response
+ Authenticator field MUST contain the correct response for the
+ pending Access-Request. Invalid packets are silently discarded.
+
+ A summary of the Access-Accept 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ | Response Authenticator |
+ | |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Attributes ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Code
+
+ 2 for Access-Accept.
+
+ Identifier
+
+ The Identifier field is a copy of the Identifier field of the
+ Access-Request which caused this Access-Accept.
+
+ Response Authenticator
+
+ The Response Authenticator value is calculated from the Access-
+ Request value, as described earlier.
+
+ Attributes
+
+ The Attribute field is variable in length, and contains a list of
+ zero or more Attributes.
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 15]
+
+RFC 2138 RADIUS April 1997
+
+
+4.3. Access-Reject
+
+ Description
+
+ If any value of the received Attributes is not acceptable, then
+ the RADIUS server MUST transmit a packet with the Code field set
+ to 3 (Access-Reject). It MAY include one or more Reply-Message
+ Attributes with a text message which the NAS MAY display to the
+ user.
+
+ A summary of the Access-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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ | Response Authenticator |
+ | |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Attributes ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Code
+
+ 3 for Access-Reject.
+
+ Identifier
+
+ The Identifier field is a copy of the Identifier field of the
+ Access-Request which caused this Access-Reject.
+
+ Response Authenticator
+
+ The Response Authenticator value is calculated from the Access-
+ Request value, as described earlier.
+
+ Attributes
+
+ The Attribute field is variable in length, and contains a list of
+ zero or more Attributes.
+
+
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 16]
+
+RFC 2138 RADIUS April 1997
+
+
+4.4. Access-Challenge
+
+ Description
+
+ If the RADIUS server desires to send the user a challenge
+ requiring a response, then the RADIUS server MUST respond to the
+ Access-Request by transmitting a packet with the Code field set to
+ 11 (Access-Challenge).
+
+ The Attributes field MAY have one or more Reply-Message
+ Attributes, and MAY have a single State Attribute, or none. No
+ other Attributes are permitted in an Access-Challenge.
+
+ On receipt of an Access-Challenge, the Identifier field is matched
+ with a pending Access-Request. Additionally, the Response
+ Authenticator field MUST contain the correct response for the
+ pending Access-Request. Invalid packets are silently discarded.
+
+ If the NAS does not support challenge/response, it MUST treat an
+ Access-Challenge as though it had received an Access-Reject
+ instead.
+
+ If the NAS supports challenge/response, receipt of a valid
+ Access-Challenge indicates that a new Access-Request SHOULD be
+ sent. The NAS MAY display the text message, if any, to the user,
+ and then prompt the user for a response. It then sends its
+ original Access-Request with a new request ID and Request
+ Authenticator, with the User-Password Attribute replaced by the
+ user's response (encrypted), and including the State Attribute
+ from the Access-Challenge, if any. Only 0 or 1 instances of the
+ State Attribute can be present in an Access-Request.
+
+ A NAS which supports PAP MAY forward the Reply-Message to the
+ dialin client and accept a PAP response which it can use as though
+ the user had entered the response. If the NAS cannot do so, it
+ should treat the Access-Challenge as though it had received an
+ Access-Reject instead.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 17]
+
+RFC 2138 RADIUS April 1997
+
+
+ A summary of the Access-Challenge 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ | Response Authenticator |
+ | |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Attributes ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Code
+
+ 11 for Access-Challenge.
+
+ Identifier
+
+ The Identifier field is a copy of the Identifier field of the
+ Access-Request which caused this Access-Challenge.
+
+ Response Authenticator
+
+ The Response Authenticator value is calculated from the Access-
+ Request value, as described earlier.
+
+ Attributes
+
+ The Attributes field is variable in length, and contains a list of
+ zero or more Attributes.
+
+5. Attributes
+
+ RADIUS Attributes carry the specific authentication, authorization,
+ information and configuration details for the request and reply.
+
+ Some Attributes MAY be included more than once. The effect of this
+ is Attribute specific, and is specified in each Attribute
+ description.
+
+ The end of the list of Attributes is indicated by the Length of the
+ RADIUS packet.
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 18]
+
+RFC 2138 RADIUS April 1997
+
+
+ A summary of the Attribute 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ | Type | Length | Value ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Type
+
+ The Type field is one octet. Up-to-date values of the RADIUS Type
+ field are specified in the most recent "Assigned Numbers" RFC [3].
+ Values 192-223 are reserved for experimental use, values 224-240
+ are reserved for implementation-specific use, and values 241-255
+ are reserved and should not be used. This specification concerns
+ the following values:
+
+ A RADIUS server MAY ignore Attributes with an unknown Type.
+
+ A RADIUS client MAY ignore Attributes with an unknown Type.
+
+ 1 User-Name
+ 2 User-Password
+ 3 CHAP-Password
+ 4 NAS-IP-Address
+ 5 NAS-Port
+ 6 Service-Type
+ 7 Framed-Protocol
+ 8 Framed-IP-Address
+ 9 Framed-IP-Netmask
+ 10 Framed-Routing
+ 11 Filter-Id
+ 12 Framed-MTU
+ 13 Framed-Compression
+ 14 Login-IP-Host
+ 15 Login-Service
+ 16 Login-TCP-Port
+ 17 (unassigned)
+ 18 Reply-Message
+ 19 Callback-Number
+ 20 Callback-Id
+ 21 (unassigned)
+ 22 Framed-Route
+ 23 Framed-IPX-Network
+ 24 State
+ 25 Class
+ 26 Vendor-Specific
+
+
+
+Rigney, et. al. Standards Track [Page 19]
+
+RFC 2138 RADIUS April 1997
+
+
+ 27 Session-Timeout
+ 28 Idle-Timeout
+ 29 Termination-Action
+ 30 Called-Station-Id
+ 31 Calling-Station-Id
+ 32 NAS-Identifier
+ 33 Proxy-State
+ 34 Login-LAT-Service
+ 35 Login-LAT-Node
+ 36 Login-LAT-Group
+ 37 Framed-AppleTalk-Link
+ 38 Framed-AppleTalk-Network
+ 39 Framed-AppleTalk-Zone
+ 40-59 (reserved for accounting)
+ 60 CHAP-Challenge
+ 61 NAS-Port-Type
+ 62 Port-Limit
+ 63 Login-LAT-Port
+
+ Length
+
+ The Length field is one octet, and indicates the length of this
+ Attribute including the Type, Length and Value fields. If an
+ Attribute is received in an Access-Request but with an invalid
+ Length, an Access-Reject SHOULD be transmitted. If an Attribute
+ is received in an Access-Accept, Access-Reject or Access-Challenge
+ packet with an invalid length, the packet MUST either be treated
+ an Access-Reject or else silently discarded.
+
+ Value
+
+ The Value field is zero or more octets and contains information
+ specific to the Attribute. The format and length of the Value
+ field is determined by the Type and Length fields.
+
+ Note that a "string" in RADIUS does not require termination by an
+ ASCII NUL because the Attribute already has a length field.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 20]
+
+RFC 2138 RADIUS April 1997
+
+
+ The format of the value field is one of four data types.
+
+ string 0-253 octets
+
+ address 32 bit value, most significant octet first.
+
+ integer 32 bit value, most significant octet first.
+
+ time 32 bit value, most significant octet first -- seconds
+ since 00:00:00 GMT, January 1, 1970. The standard
+ Attributes do not use this data type but it is presented
+ here for possible use within Vendor-Specific attributes.
+
+
+5.1. User-Name
+
+ Description
+
+ This Attribute indicates the name of the user to be authenticated.
+ It is only used in Access-Request packets.
+
+ A summary of the User-Name Attribute 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ | Type | Length | String ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Type
+
+ 1 for User-Name.
+
+ Length
+
+ >= 3
+
+ String
+
+ The String field is one or more octets. The NAS may limit the
+ maximum length of the User-Name but the ability to handle at least
+ 63 octets is recommended.
+
+
+
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 21]
+
+RFC 2138 RADIUS April 1997
+
+
+ The format of the username MAY be one of several forms:
+
+ monolithic Consisting only of alphanumeric characters. This
+ simple form might be used to locally manage a NAS.
+
+ simple Consisting only of printable ASCII characters.
+
+ name@fqdn SMTP address. The Fully Qualified Domain Name (with or
+ without trailing dot) indicates the realm in which the
+ name part applies.
+
+ distinguished name
+ A name in ASN.1 form used in Public Key authentication
+ systems.
+
+5.2. User-Password
+
+ Description
+
+ This Attribute indicates the password of the user to be
+ authenticated, or the user's input following an Access-Challenge.
+ It is only used in Access-Request packets.
+
+ On transmission, the password is hidden. The password is first
+ padded at the end with nulls to a multiple of 16 octets. A one-
+ way MD5 hash is calculated over a stream of octets consisting of
+ the shared secret followed by the Request Authenticator. This
+ value is XORed with the first 16 octet segment of the password and
+ placed in the first 16 octets of the String field of the User-
+ Password Attribute.
+
+ If the password is longer than 16 characters, a second one-way MD5
+ hash is calculated over a stream of octets consisting of the
+ shared secret followed by the result of the first xor. That hash
+ is XORed with the second 16 octet segment of the password and
+ placed in the second 16 octets of the String field of the User-
+ Password Attribute.
+
+ If necessary, this operation is repeated, with each xor result
+ being used along with the shared secret to generate the next hash
+ to xor the next segment of the password, to no more than 128
+ characters.
+
+ The method is taken from the book "Network Security" by Kaufman,
+ Perlman and Speciner [4] pages 109-110. A more precise
+ explanation of the method follows:
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 22]
+
+RFC 2138 RADIUS April 1997
+
+
+ Call the shared secret S and the pseudo-random 128-bit Request
+ Authenticator RA. Break the password into 16-octet chunks p1, p2,
+ etc. with the last one padded at the end with nulls to a 16-octet
+ boundary. Call the ciphertext blocks c(1), c(2), etc. We'll need
+ intermediate values b1, b2, etc.
+
+ b1 = MD5(S + RA) c(1) = p1 xor b1
+ b2 = MD5(S + c(1)) c(2) = p2 xor b2
+ . .
+ . .
+ . .
+ bi = MD5(S + c(i-1)) c(i) = pi xor bi
+
+ The String will contain c(1)+c(2)+...+c(i) where + denotes
+ concatenation.
+
+ On receipt, the process is reversed to yield the original
+ password.
+
+ A summary of the User-Password Attribute 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ | Type | Length | String ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Type
+
+ 2 for User-Password.
+
+ Length
+
+ At least 18 and no larger than 130.
+
+ String
+
+ The String field is between 16 and 128 octets long, inclusive.
+
+5.3. CHAP-Password
+
+ Description
+
+ This Attribute indicates the response value provided by a PPP
+ Challenge-Handshake Authentication Protocol (CHAP) user in
+ response to the challenge. It is only used in Access-Request
+ packets.
+
+
+
+Rigney, et. al. Standards Track [Page 23]
+
+RFC 2138 RADIUS April 1997
+
+
+ The CHAP challenge value is found in the CHAP-Challenge Attribute
+ (60) if present in the packet, otherwise in the Request
+ Authenticator field.
+
+ A summary of the CHAP-Password Attribute 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 4 5 6 7 8 9
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ | Type | Length | CHAP Ident | String ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Type
+
+ 3 for CHAP-Password.
+
+ Length
+
+ 19
+
+ CHAP Ident
+
+ This field is one octet, and contains the CHAP Identifier from the
+ user's CHAP Response.
+
+ String
+
+ The String field is 16 octets, and contains the CHAP Response from
+ the user.
+
+5.4. NAS-IP-Address
+
+ Description
+
+ This Attribute indicates the identifying IP Address of the NAS
+ which is requesting authentication of the user. It is only used
+ in Access-Request packets. Either NAS-IP-Address or NAS-
+ Identifier SHOULD be present in an Access-Request packet.
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 24]
+
+RFC 2138 RADIUS April 1997
+
+
+ A summary of the NAS-IP-Address Attribute 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 | Address
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Address (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 4 for NAS-IP-Address.
+
+ Length
+
+ 6
+
+ Address
+
+ The Address field is four octets.
+
+5.5. NAS-Port
+
+ Description
+
+ This Attribute indicates the physical port number of the NAS which
+ is authenticating the user. It is only used in Access-Request
+ packets. Note that this is using "port" in its sense of a
+ physical connection on the NAS, not in the sense of a TCP or UDP
+ port number. Either NAS-Port or NAS-Port-Type (61) or both SHOULD
+ be present in an Access-Request packet, if the NAS differentiates
+ among its ports.
+
+ A summary of the NAS-Port Attribute format is shown below. The
+ fields are transmitted from left to right.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 25]
+
+RFC 2138 RADIUS April 1997
+
+
+ 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 5 for NAS-Port.
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets. Despite the size of the field,
+ values range from 0 to 65535.
+
+5.6. Service-Type
+
+ Description
+
+ This Attribute indicates the type of service the user has
+ requested, or the type of service to be provided. It MAY be used
+ in both Access-Request and Access-Accept packets. A NAS is not
+ required to implement all of these service types, and MUST treat
+ unknown or unsupported Service-Types as though an Access-Reject
+ had been received instead.
+
+ A summary of the Service-Type Attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 6 for Service-Type.
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 26]
+
+RFC 2138 RADIUS April 1997
+
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets.
+
+ 1 Login
+ 2 Framed
+ 3 Callback Login
+ 4 Callback Framed
+ 5 Outbound
+ 6 Administrative
+ 7 NAS Prompt
+ 8 Authenticate Only
+ 9 Callback NAS Prompt
+
+
+ The service types are defined as follows when used in an Access-
+ Accept. When used in an Access-Request, they should be considered
+ to be a hint to the RADIUS server that the NAS has reason to
+ believe the user would prefer the kind of service indicated, but
+ the server is not required to honor the hint.
+
+ Login The user should be connected to a host.
+
+ Framed A Framed Protocol should be started for the
+ User, such as PPP or SLIP.
+
+ Callback Login The user should be disconnected and called
+ back, then connected to a host.
+
+ Callback Framed The user should be disconnected and called
+ back, then a Framed Protocol should be started
+ for the User, such as PPP or SLIP.
+
+ Outbound The user should be granted access to outgoing
+ devices.
+
+ Administrative The user should be granted access to the
+ administrative interface to the NAS from which
+ privileged commands can be executed.
+
+ NAS Prompt The user should be provided a command prompt
+ on the NAS from which non-privileged commands
+ can be executed.
+
+
+
+
+Rigney, et. al. Standards Track [Page 27]
+
+RFC 2138 RADIUS April 1997
+
+
+ Authenticate Only Only Authentication is requested, and no
+ authorization information needs to be returned
+ in the Access-Accept (typically used by proxy
+ servers rather than the NAS itself).
+
+ Callback NAS Prompt The user should be disconnected and called
+ back, then provided a command prompt on the
+ NAS from which non-privileged commands can be
+ executed.
+
+5.7. Framed-Protocol
+
+ Description
+
+ This Attribute indicates the framing to be used for framed access.
+ It MAY be used in both Access-Request and Access-Accept packets.
+
+ A summary of the Framed-Protocol Attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 7 for Framed-Protocol.
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets.
+
+ 1 PPP
+ 2 SLIP
+ 3 AppleTalk Remote Access Protocol (ARAP)
+ 4 Gandalf proprietary SingleLink/MultiLink protocol
+ 5 Xylogics proprietary IPX/SLIP
+
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 28]
+
+RFC 2138 RADIUS April 1997
+
+
+5.8. Framed-IP-Address
+
+ Description
+
+ This Attribute indicates the address to be configured for the
+ user. It MAY be used in Access-Accept packets. It MAY be used in
+ an Access-Request packet as a hint by the NAS to the server that
+ it would prefer that address, but the server is not required to
+ honor the hint.
+
+ A summary of the Framed-IP-Address Attribute 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 | Address
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Address (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 8 for Framed-IP-Address.
+
+ Length
+
+ 6
+
+ Address
+
+ The Address field is four octets. The value 0xFFFFFFFF indicates
+ that the NAS should allow the user to select an address (e.g.
+ Negotiated). The value 0xFFFFFFFE indicates that the NAS should
+ select an address for the user (e.g. Assigned from a pool of
+ addresses kept by the NAS). Other valid values indicate that the
+ NAS should use that value as the user's IP address.
+
+5.9. Framed-IP-Netmask
+
+ Description
+
+ This Attribute indicates the IP netmask to be configured for the
+ user when the user is a router to a network. It MAY be used in
+ Access-Accept packets. It MAY be used in an Access-Request packet
+ as a hint by the NAS to the server that it would prefer that
+ netmask, but the server is not required to honor the hint.
+
+
+
+
+Rigney, et. al. Standards Track [Page 29]
+
+RFC 2138 RADIUS April 1997
+
+
+ A summary of the Framed-IP-Netmask Attribute 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 | Address
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Address (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 9 for Framed-IP-Netmask.
+
+ Length
+
+ 6
+
+ Address
+
+ The Address field is four octets specifying the IP netmask of the
+ user.
+
+5.10. Framed-Routing
+
+ Description
+
+ This Attribute indicates the routing method for the user, when the
+ user is a router to a network. It is only used in Access-Accept
+ packets.
+
+ A summary of the Framed-Routing Attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 10 for Framed-Routing.
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 30]
+
+RFC 2138 RADIUS April 1997
+
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets.
+
+ 0 None
+ 1 Send routing packets
+ 2 Listen for routing packets
+ 3 Send and Listen
+
+5.11. Filter-Id
+
+ Description
+
+ This Attribute indicates the name of the filter list for this
+ user. Zero or more Filter-Id attributes MAY be sent in an
+ Access-Accept packet.
+
+ Identifying a filter list by name allows the filter to be used on
+ different NASes without regard to filter-list implementation
+ details.
+
+ A summary of the Filter-Id Attribute 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ | Type | Length | String ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Type
+
+ 11 for Filter-Id.
+
+ Length
+
+ >= 3
+
+
+
+
+
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 31]
+
+RFC 2138 RADIUS April 1997
+
+
+ String
+
+ The String field is one 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 from the range 32
+ through 126 decimal.
+
+5.12. Framed-MTU
+
+ Description
+
+ This Attribute indicates the Maximum Transmission Unit to be
+ configured for the user, when it is not negotiated by some other
+ means (such as PPP). It is only used in Access-Accept packets.
+
+ A summary of the Framed-MTU Attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 12 for Framed-MTU.
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets. Despite the size of the field,
+ values range from 64 to 65535.
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 32]
+
+RFC 2138 RADIUS April 1997
+
+
+5.13. Framed-Compression
+
+ Description
+
+ This Attribute indicates a compression protocol to be used for the
+ link. It MAY be used in Access-Accept packets. It MAY be used in
+ an Access-Request packet as a hint to the server that the NAS
+ would prefer to use that compression, but the server is not
+ required to honor the hint.
+
+ More than one compression protocol Attribute MAY be sent. It is
+ the responsibility of the NAS to apply the proper compression
+ protocol to appropriate link traffic.
+
+ A summary of the Framed-Compression Attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 13 for Framed-Compression.
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets.
+
+ 0 None
+ 1 VJ TCP/IP header compression [5]
+ 2 IPX header compression
+
+5.14. Login-IP-Host
+
+ Description
+
+ This Attribute indicates the system with which to connect the
+ user, when the Login-Service Attribute is included. It MAY be
+ used in Access-Accept packets. It MAY be used in an Access-
+
+
+
+Rigney, et. al. Standards Track [Page 33]
+
+RFC 2138 RADIUS April 1997
+
+
+ Request packet as a hint to the server that the NAS would prefer
+ to use that host, but the server is not required to honor the
+ hint.
+
+ A summary of the Login-IP-Host Attribute 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 | Address
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Address (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 14 for Login-IP-Host.
+
+ Length
+
+ 6
+
+ Address
+
+ The Address field is four octets. The value 0xFFFFFFFF indicates
+ that the NAS SHOULD allow the user to select an address. The
+ value 0 indicates that the NAS SHOULD select a host to connect the
+ user to. Other values indicate the address the NAS SHOULD connect
+ the user to.
+
+5.15. Login-Service
+
+ Description
+
+ This Attribute indicates the service which should be used to
+ connect the user to the login host. It is only used in Access-
+ Accept packets.
+
+ A summary of the Login-Service Attribute format is shown below. The
+ fields are transmitted from left to right.
+
+
+
+
+
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 34]
+
+RFC 2138 RADIUS April 1997
+
+
+ 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 15 for Login-Service.
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets.
+
+ 0 Telnet
+ 1 Rlogin
+ 2 TCP Clear
+ 3 PortMaster (proprietary)
+ 4 LAT
+
+5.16. Login-TCP-Port
+
+ Description
+
+ This Attribute indicates the TCP port with which the user is to be
+ connected, when the Login-Service Attribute is also present. It
+ is only used in Access-Accept packets.
+
+ A summary of the Login-TCP-Port Attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 16 for Login-TCP-Port.
+
+
+
+Rigney, et. al. Standards Track [Page 35]
+
+RFC 2138 RADIUS April 1997
+
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets. Despite the size of the field,
+ values range from 0 to 65535.
+
+5.17. (unassigned)
+
+ Description
+
+ ATTRIBUTE TYPE 17 HAS NOT BEEN ASSIGNED.
+
+5.18. Reply-Message
+
+ Description
+
+ This Attribute indicates text which MAY be displayed to the user.
+
+ When used in an Access-Accept, it is the success message.
+
+ When used in an Access-Reject, it is the failure message. It MAY
+ indicate a dialog message to prompt the user before another
+ Access-Request attempt.
+
+ When used in an Access-Challenge, it MAY indicate a dialog message
+ to prompt the user for a response.
+
+ Multiple Reply-Message's MAY be included and if any are displayed,
+ they MUST be displayed in the same order as they appear in the
+ packet.
+
+ A summary of the Reply-Message Attribute 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ | Type | Length | String ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+
+ Type
+
+ 18 for Reply-Message.
+
+
+
+
+Rigney, et. al. Standards Track [Page 36]
+
+RFC 2138 RADIUS April 1997
+
+
+ Length
+
+ >= 3
+
+ String
+
+ The String field is one 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 from the
+ range 10, 13, and 32 through 126 decimal. Mechanisms for
+ extension to other character sets are beyond the scope of this
+ specification.
+
+5.19. Callback-Number
+
+ Description
+
+ This Attribute indicates a dialing string to be used for callback.
+ It MAY be used in Access-Accept packets. It MAY be used in an
+ Access-Request packet as a hint to the server that a Callback
+ service is desired, but the server is not required to honor the
+ hint.
+
+ A summary of the Callback-Number Attribute 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ | Type | Length | String ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Type
+
+ 19 for Callback-Number.
+
+ Length
+
+ >= 3
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 37]
+
+RFC 2138 RADIUS April 1997
+
+
+ String
+
+ The String field is one or more octets. The actual format of the
+ information is site or application specific, and a robust
+ implementation SHOULD support the field as undistinguished octets.
+
+ The codification of the range of allowed usage of this field is
+ outside the scope of this specification.
+
+5.20. Callback-Id
+
+ Description
+
+ This Attribute indicates the name of a place to be called, to be
+ interpreted by the NAS. It MAY be used in Access-Accept packets.
+
+ A summary of the Callback-Id Attribute 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ | Type | Length | String ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Type
+
+ 20 for Callback-Id.
+
+ Length
+
+ >= 3
+
+ String
+
+ The String field is one or more octets. The actual format of the
+ information is site or application specific, and a robust
+ implementation SHOULD support the field as undistinguished octets.
+ The codification of the range of allowed usage of this field is
+ outside the scope of this specification.
+
+5.21. (unassigned)
+
+ Description
+
+ ATTRIBUTE TYPE 21 HAS NOT BEEN ASSIGNED.
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 38]
+
+RFC 2138 RADIUS April 1997
+
+
+5.22. Framed-Route
+
+ Description
+
+ This Attribute provides routing information to be configured for
+ the user on the NAS. It is used in the Access-Accept packet and
+ can appear multiple times.
+
+ A summary of the Framed-Route Attribute 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 | String...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Type
+
+ 22 for Framed-Route.
+
+ Length
+
+ >= 3
+
+ String
+
+ The String field is one 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 from the range 32
+ through 126 decimal.
+
+ For IP routes, it SHOULD contain a destination prefix in dotted
+ quad form optionally followed by a slash and a decimal length
+ specifier stating how many high order bits of the prefix should be
+ used. That is followed by a space, a gateway address in dotted
+ quad form, a space, and one or more metrics separated by spaces.
+ For example, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400". The length
+ specifier may be omitted in which case it should default to 8 bits
+ for class A prefixes, 16 bits for class B prefixes, and 24 bits
+ for class C prefixes. For example, "192.168.1.0 192.168.1.1 1".
+
+ Whenever the gateway address is specified as "0.0.0.0" the IP
+ address of the user SHOULD be used as the gateway address.
+
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 39]
+
+RFC 2138 RADIUS April 1997
+
+
+5.23. Framed-IPX-Network
+
+ Description
+
+ This Attribute indicates the IPX Network number to be configured
+ for the user. It is used in Access-Accept packets.
+
+ A summary of the Framed-IPX-Network Attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 23 for Framed-IPX-Network.
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets. The value 0xFFFFFFFE indicates
+ that the NAS should select an IPX network for the user (e.g.
+ assigned from a pool of one or more IPX networks kept by the NAS).
+ Other values should be used as the IPX network for the link to the
+ user.
+
+5.24. State
+
+ Description
+
+ This Attribute is available to be sent by the server to the client
+ in an Access-Challenge and MUST be sent unmodified from the client
+ to the server in the new Access-Request reply to that challenge,
+ if any.
+
+
+
+
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 40]
+
+RFC 2138 RADIUS April 1997
+
+
+ This Attribute is available to be sent by the server to the client
+ in an Access-Accept that also includes a Termination-Action
+ Attribute with the value of RADIUS-Request. If the NAS performs
+ the Termination-Action by sending a new Access-Request upon
+ termination of the current session, it MUST include the State
+ attribute unchanged in that Access-Request.
+
+ In either usage, no interpretation by the client should be made.
+ A packet may have only one State Attribute. Usage of the State
+ Attribute is implementation dependent.
+
+ A summary of the State Attribute 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ | Type | Length | String ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Type
+
+ 24 for State.
+
+ Length
+
+ >= 3
+
+ String
+
+ The String field is one or more octets. The actual format of the
+ information is site or application specific, and a robust
+ implementation SHOULD support the field as undistinguished octets.
+
+ The codification of the range of allowed usage of this field is
+ outside the scope of this specification.
+
+5.25. Class
+
+ Description
+
+ This Attribute is available to be sent by the server to the client
+ in an Access-Accept and should be sent unmodified by the client to
+ the accounting server as part of the Accounting-Request packet if
+ accounting is supported. No interpretation by the client should
+ be made.
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 41]
+
+RFC 2138 RADIUS April 1997
+
+
+ A summary of the Class Attribute 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ | Type | Length | String ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Type
+
+ 25 for Class.
+
+ Length
+
+ >= 3
+
+ String
+
+ The String field is one or more octets. The actual format of the
+ information is site or application specific, and a robust
+ implementation SHOULD support the field as undistinguished octets.
+
+ The codification of the range of allowed usage of this field is
+ outside the scope of this specification.
+
+5.26. Vendor-Specific
+
+ Description
+
+ This Attribute is available to allow vendors to support their own
+ extended Attributes not suitable for general usage. It MUST not
+ affect the operation of the RADIUS protocol.
+
+ Servers not equipped to interpret the vendor-specific information
+ sent by a client MUST ignore it (although it may be reported).
+ Clients which do not receive desired vendor-specific information
+ SHOULD make an attempt to operate without it, although they may do
+ so (and report they are doing so) in a degraded mode.
+
+ A summary of the Vendor-Specific Attribute format is shown below.
+ The fields are transmitted from left to right.
+
+
+
+
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 42]
+
+RFC 2138 RADIUS April 1997
+
+
+ 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 | Vendor-Id
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Vendor-Id (cont) | String...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Type
+
+ 26 for Vendor-Specific.
+
+ Length
+
+ >= 7
+
+ Vendor-Id
+
+ The high-order octet is 0 and the low-order 3 octets are the SMI
+ Network Management Private Enterprise Code of the Vendor in
+ network byte order, as defined in the Assigned Numbers RFC [3].
+
+ String
+
+ The String field is one or more octets. The actual format of the
+ information is site or application specific, and a robust
+ implementation SHOULD support the field as undistinguished octets.
+
+ The codification of the range of allowed usage of this field is
+ outside the scope of this specification.
+
+ It SHOULD be encoded as a sequence of vendor type / vendor length
+ / value fields, as follows. The Attribute-Specific field is
+ dependent on the vendor's definition of that attribute. An
+ example encoding of the Vendor-Specific attribute using this
+ method 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Vendor-Id
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Vendor-Id (cont) | Vendor type | Vendor length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Attribute-Specific...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 43]
+
+RFC 2138 RADIUS April 1997
+
+
+5.27. Session-Timeout
+
+ Description
+
+ This Attribute sets the maximum number of seconds of service to be
+ provided to the user before termination of the session or prompt.
+ This Attribute is available to be sent by the server to the client
+ in an Access-Accept or Access-Challenge.
+
+ A summary of the Session-Timeout Attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 27 for Session-Timeout.
+
+ Length
+
+ 6
+
+ Value
+
+ The field is 4 octets, containing a 32-bit unsigned integer with
+ the maximum number of seconds this user should be allowed to
+ remain connected by the NAS.
+
+5.28. Idle-Timeout
+
+ Description
+
+ This Attribute sets the maximum number of consecutive seconds of
+ idle connection allowed to the user before termination of the
+ session or prompt. This Attribute is available to be sent by the
+ server to the client in an Access-Accept or Access-Challenge.
+
+
+
+
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 44]
+
+RFC 2138 RADIUS April 1997
+
+
+ A summary of the Idle-Timeout Attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 28 for Idle-Timeout.
+
+ Length
+
+ 6
+
+ Value
+
+ The field is 4 octets, containing a 32-bit unsigned integer with
+ the maximum number of consecutive seconds of idle time this user
+ should be permitted before being disconnected by the NAS.
+
+5.29. Termination-Action
+
+ Description
+
+ This Attribute indicates what action the NAS should take when the
+ specified service is completed. It is only used in Access-Accept
+ packets.
+
+ A summary of the Termination-Action Attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 29 for Termination-Action.
+
+
+
+
+Rigney, et. al. Standards Track [Page 45]
+
+RFC 2138 RADIUS April 1997
+
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets.
+
+ 0 Default
+ 1 RADIUS-Request
+
+ If the Value is set to RADIUS-Request, upon termination of the
+ specified service the NAS MAY send a new Access-Request to the
+ RADIUS server, including the State attribute if any.
+
+5.30. Called-Station-Id
+
+ Description
+
+ This Attribute allows the NAS to send in the Access-Request packet
+ the phone number that the user called, using Dialed Number
+ Identification (DNIS) or similar technology. Note that this may be
+ different from the phone number the call comes in on. It is only
+ used in Access-Request packets.
+
+ A summary of the Called-Station-Id Attribute 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ | Type | Length | String ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+
+ Type
+
+ 30 for Called-Station-Id.
+
+ Length
+
+ >= 3
+
+ String
+
+ The String field is one or more octets, containing the phone
+ number that the user's call came in on.
+
+
+
+
+Rigney, et. al. Standards Track [Page 46]
+
+RFC 2138 RADIUS April 1997
+
+
+ The actual format of the information is site or application
+ specific. Printable ASCII is recommended, but a robust
+ implementation SHOULD support the field as undistinguished octets.
+
+ The codification of the range of allowed usage of this field is
+ outside the scope of this specification.
+
+5.31. Calling-Station-Id
+
+ Description
+
+ This Attribute allows the NAS to send in the Access-Request packet
+ the phone number that the call came from, using Automatic Number
+ Identification (ANI) or similar technology. It is only used in
+ Access-Request packets.
+
+ A summary of the Calling-Station-Id Attribute 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ | Type | Length | String ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Type
+
+ 31 for Calling-Station-Id.
+
+ Length
+
+ >= 3
+
+ String
+
+ The String field is one or more octets, containing the phone
+ number that the user placed the call from.
+
+ The actual format of the information is site or application
+ specific. Printable ASCII is recommended, but a robust
+ implementation SHOULD support the field as undistinguished octets.
+
+ The codification of the range of allowed usage of this field is
+ outside the scope of this specification.
+
+
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 47]
+
+RFC 2138 RADIUS April 1997
+
+
+5.32. NAS-Identifier
+
+ Description
+
+ This Attribute contains a string identifying the NAS originating
+ the Access-Request. It is only used in Access-Request packets.
+ Either NAS-IP-Address or NAS-Identifier SHOULD be present in an
+ Access-Request packet.
+
+ A summary of the NAS-Identifier Attribute 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ | Type | Length | String ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Type
+
+ 32 for NAS-Identifier.
+
+ Length
+
+ >= 3
+
+ String
+
+ The String field is one or more octets, and should be unique to
+ the NAS within the scope of the RADIUS server. For example, a
+ fully qualified domain name would be suitable as a NAS-Identifier.
+
+ The actual format of the information is site or application
+ specific, and a robust implementation SHOULD support the field as
+ undistinguished octets.
+
+ The codification of the range of allowed usage of this field is
+ outside the scope of this specification.
+
+5.33. Proxy-State
+
+ Description
+
+ This Attribute is available to be sent by a proxy server to
+ another server when forwarding an Access-Request and MUST be
+ returned unmodified in the Access-Accept, Access-Reject or
+ Access-Challenge. This attribute should be removed by the proxy
+ server before the response is forwarded to the NAS.
+
+
+
+Rigney, et. al. Standards Track [Page 48]
+
+RFC 2138 RADIUS April 1997
+
+
+ Usage of the Proxy-State Attribute is implementation dependent. A
+ description of its function is outside the scope of this
+ specification.
+
+ A summary of the Proxy-State Attribute 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ | Type | Length | String ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Type
+
+ 33 for Proxy-State.
+
+ Length
+
+ >= 3
+
+ String
+
+ The String field is one or more octets. The actual format of the
+ information is site or application specific, and a robust
+ implementation SHOULD support the field as undistinguished octets.
+
+ The codification of the range of allowed usage of this field is
+ outside the scope of this specification.
+
+5.34. Login-LAT-Service
+
+ Description
+
+ This Attribute indicates the system with which the user is to be
+ connected by LAT. It MAY be used in Access-Accept packets, but
+ only when LAT is specified as the Login-Service. It MAY be used
+ in an Access-Request packet as a hint to the server, but the
+ server is not required to honor the hint.
+
+ Administrators use the service attribute when dealing with
+ clustered systems, such as a VAX or Alpha cluster. In such an
+ environment several different time sharing hosts share the same
+ resources (disks, printers, etc.), and administrators often
+ configure each to offer access (service) to each of the shared
+ resources. In this case, each host in the cluster advertises its
+ services through LAT broadcasts.
+
+
+
+
+Rigney, et. al. Standards Track [Page 49]
+
+RFC 2138 RADIUS April 1997
+
+
+ Sophisticated users often know which service providers (machines)
+ are faster and tend to use a node name when initiating a LAT
+ connection. Alternately, some administrators want particular
+ users to use certain machines as a primitive form of load
+ balancing (although LAT knows how to do load balancing itself).
+
+ A summary of the Login-LAT-Service Attribute 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ | Type | Length | String ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+
+ Type
+
+ 34 for Login-LAT-Service.
+
+ Length
+
+ >= 3
+
+ String
+
+ The String field is one or more octets, and contains the identity
+ of the LAT service to use. The LAT Architecture allows this
+ string to contain $ (dollar), - (hyphen), . (period), _
+ (underscore), numerics, upper and lower case alphabetics, and the
+ ISO Latin-1 character set extension [6]. All LAT string
+ comparisons are case insensitive.
+
+5.35. Login-LAT-Node
+
+ Description
+
+ This Attribute indicates the Node with which the user is to be
+ automatically connected by LAT. It MAY be used in Access-Accept
+ packets, but only when LAT is specified as the Login-Service. It
+ MAY be used in an Access-Request packet as a hint to the server,
+ but the server is not required to honor the hint.
+
+ A summary of the Login-LAT-Node Attribute format is shown below. The
+ fields are transmitted from left to right.
+
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 50]
+
+RFC 2138 RADIUS April 1997
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ | Type | Length | String ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Type
+
+ 35 for Login-LAT-Node.
+
+ Length
+
+ >= 3
+
+ String
+
+ The String field is one or more octets, and contains the identity
+ of the LAT Node to connect the user to. The LAT Architecture
+ allows this string to contain $ (dollar), - (hyphen), . (period),
+ _ (underscore), numerics, upper and lower case alphabetics, and
+ the ISO Latin-1 character set extension. All LAT string
+ comparisons are case insensitive.
+
+5.36. Login-LAT-Group
+
+ Description
+
+ This Attribute contains a string identifying the LAT group codes
+ which this user is authorized to use. It MAY be used in Access-
+ Accept packets, but only when LAT is specified as the Login-
+ Service. It MAY be used in an Access-Request packet as a hint to
+ the server, but the server is not required to honor the hint.
+
+ LAT supports 256 different group codes, which LAT uses as a form
+ of access rights. LAT encodes the group codes as a 256 bit
+ bitmap.
+
+ Administrators can assign one or more of the group code bits at
+ the LAT service provider; it will only accept LAT connections that
+ have these group codes set in the bit map. The administrators
+ assign a bitmap of authorized group codes to each user; LAT gets
+ these from the operating system, and uses these in its requests to
+ the service providers.
+
+
+
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 51]
+
+RFC 2138 RADIUS April 1997
+
+
+ A summary of the Login-LAT-Group Attribute 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ | Type | Length | String ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Type
+
+ 36 for Login-LAT-Group.
+
+ Length
+
+ 34
+
+ String
+
+ The String field is a 32 octet bit map, most significant octet
+ first. A robust implementation SHOULD support the field as
+ undistinguished octets.
+
+ The codification of the range of allowed usage of this field is
+ outside the scope of this specification.
+
+5.37. Framed-AppleTalk-Link
+
+ Description
+
+ This Attribute indicates the AppleTalk network number which should
+ be used for the serial link to the user, which is another
+ AppleTalk router. It is only used in Access-Accept packets. It
+ is never used when the user is not another router.
+
+ A summary of the Framed-AppleTalk-Link Attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 52]
+
+RFC 2138 RADIUS April 1997
+
+
+ Type
+
+ 37 for Framed-AppleTalk-Link.
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets. Despite the size of the field,
+ values range from 0 to 65535. The special value of 0 indicates
+ that this is an unnumbered serial link. A value of 1-65535 means
+ that the serial line between the NAS and the user should be
+ assigned that value as an AppleTalk network number.
+
+5.38. Framed-AppleTalk-Network
+
+ Description
+
+ This Attribute indicates the AppleTalk Network number which the
+ NAS should probe to allocate an AppleTalk node for the user. It
+ is only used in Access-Accept packets. It is never used when the
+ user is another router. Multiple instances of this Attribute
+ indicate that the NAS may probe using any of the network numbers
+ specified.
+
+ A summary of the Framed-AppleTalk-Network Attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 38 for Framed-AppleTalk-Network.
+
+ Length
+
+ 6
+
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 53]
+
+RFC 2138 RADIUS April 1997
+
+
+ Value
+
+ The Value field is four octets. Despite the size of the field,
+ values range from 0 to 65535. The special value 0 indicates that
+ the NAS should assign a network for the user, using its default
+ cable range. A value between 1 and 65535 (inclusive) indicates
+ the AppleTalk Network the NAS should probe to find an address for
+ the user.
+
+5.39. Framed-AppleTalk-Zone
+
+ Description
+
+ This Attribute indicates the AppleTalk Default Zone to be used for
+ this user. It is only used in Access-Accept packets. Multiple
+ instances of this attribute in the same packet are not allowed.
+
+ A summary of the Framed-AppleTalk-Zone Attribute 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 4
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ | Type | Length | String ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Type
+
+ 39 for Framed-AppleTalk-Zone.
+
+ Length
+
+ >= 3
+
+ String
+
+ The name of the Default AppleTalk Zone to be used for this user.
+ A robust implementation SHOULD support the field as
+ undistinguished octets.
+
+ The codification of the range of allowed usage of this field is
+ outside the scope of this specification.
+
+
+
+
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 54]
+
+RFC 2138 RADIUS April 1997
+
+
+5.40. CHAP-Challenge
+
+ Description
+
+ This Attribute contains the CHAP Challenge sent by the NAS to a
+ PPP Challenge-Handshake Authentication Protocol (CHAP) user. It
+ is only used in Access-Request packets.
+
+ If the CHAP challenge value is 16 octets long it MAY be placed in
+ the Request Authenticator field instead of using this attribute.
+
+ A summary of the CHAP-Challenge Attribute 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 | String...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Type
+
+ 60 for CHAP-Challenge.
+
+ Length
+
+ >= 7
+
+ String
+
+ The String field contains the CHAP Challenge.
+
+5.41. NAS-Port-Type
+
+ Description
+
+ This Attribute indicates the type of the physical port of the NAS
+ which is authenticating the user. It can be used instead of or in
+ addition to the NAS-Port (5) attribute. It is only used in
+ Access-Request packets. Either NAS-Port (5) or NAS-Port-Type or
+ both SHOULD be present in an Access-Request packet, if the NAS
+ differentiates among its ports.
+
+
+
+
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 55]
+
+RFC 2138 RADIUS April 1997
+
+
+ A summary of the NAS-Port-Type Attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 61 for NAS-Port-Type.
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets. "Virtual" refers to a connection
+ to the NAS via some transport protocol, instead of through a
+ physical port. For example, if a user telnetted into a NAS to
+ authenticate himself as an Outbound-User, the Access-Request might
+ include NAS-Port-Type = Virtual as a hint to the RADIUS server
+ that the user was not on a physical port.
+
+ 0 Async
+ 1 Sync
+ 2 ISDN Sync
+ 3 ISDN Async V.120
+ 4 ISDN Async V.110
+ 5 Virtual
+
+5.42. Port-Limit
+
+ Description
+
+ This Attribute sets the maximum number of ports to be provided to
+ the user by the NAS. This Attribute MAY be sent by the server to
+ the client in an Access-Accept packet. It is intended for use in
+ conjunction with Multilink PPP [7] or similar uses. It MAY also
+ be sent by the NAS to the server as a hint that that many ports
+ are desired for use, but the server is not required to honor the
+ hint.
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 56]
+
+RFC 2138 RADIUS April 1997
+
+
+ A summary of the Port-Limit Attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 62 for Port-Limit.
+
+ Length
+
+ 6
+
+ Value
+
+ The field is 4 octets, containing a 32-bit unsigned integer with
+ the maximum number of ports this user should be allowed to connect
+ to on the NAS.
+
+5.43. Login-LAT-Port
+
+ Description
+
+ This Attribute indicates the Port with which the user is to be
+ connected by LAT. It MAY be used in Access-Accept packets, but
+ only when LAT is specified as the Login-Service. It MAY be used
+ in an Access-Request packet as a hint to the server, but the
+ server is not required to honor the hint.
+
+ A summary of the Login-LAT-Port Attribute 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ | Type | Length | String ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Type
+
+ 63 for Login-LAT-Port.
+
+
+
+
+Rigney, et. al. Standards Track [Page 57]
+
+RFC 2138 RADIUS April 1997
+
+
+ Length
+
+ >= 3
+
+ String
+
+ The String field is one or more octets, and contains the identity
+ of the LAT port to use. The LAT Architecture allows this string
+ to contain $ (dollar), - (hyphen), . (period), _ (underscore),
+ numerics, upper and lower case alphabetics, and the ISO Latin-1
+ character set extension. All LAT string comparisons are case
+ insensitive.
+
+5.44. Table of Attributes
+
+ The following table provides a guide to which attributes may be found
+ in which kinds of packets, and in what quantity.
+
+ Request Accept Reject Challenge # Attribute
+ 1 0 0 0 1 User-Name
+ 0-1 0 0 0 2 User-Password [Note 1]
+ 0-1 0 0 0 3 CHAP-Password [Note 1]
+ 0-1 0 0 0 4 NAS-IP-Address
+ 0-1 0 0 0 5 NAS-Port
+ 0-1 0-1 0 0 6 Service-Type
+ 0-1 0-1 0 0 7 Framed-Protocol
+ 0-1 0-1 0 0 8 Framed-IP-Address
+ 0-1 0-1 0 0 9 Framed-IP-Netmask
+ 0 0-1 0 0 10 Framed-Routing
+ 0 0+ 0 0 11 Filter-Id
+ 0 0-1 0 0 12 Framed-MTU
+ 0+ 0+ 0 0 13 Framed-Compression
+ 0+ 0+ 0 0 14 Login-IP-Host
+ 0 0-1 0 0 15 Login-Service
+ 0 0-1 0 0 16 Login-TCP-Port
+ 0 0+ 0+ 0+ 18 Reply-Message
+ 0-1 0-1 0 0 19 Callback-Number
+ 0 0-1 0 0 20 Callback-Id
+ 0 0+ 0 0 22 Framed-Route
+ 0 0-1 0 0 23 Framed-IPX-Network
+ 0-1 0-1 0 0-1 24 State
+ 0 0+ 0 0 25 Class
+ 0+ 0+ 0 0+ 26 Vendor-Specific
+ 0 0-1 0 0-1 27 Session-Timeout
+ 0 0-1 0 0-1 28 Idle-Timeout
+ 0 0-1 0 0 29 Termination-Action
+ 0-1 0 0 0 30 Called-Station-Id
+ 0-1 0 0 0 31 Calling-Station-Id
+
+
+
+Rigney, et. al. Standards Track [Page 58]
+
+RFC 2138 RADIUS April 1997
+
+
+ 0-1 0 0 0 32 NAS-Identifier
+ 0+ 0+ 0+ 0+ 33 Proxy-State
+ 0-1 0-1 0 0 34 Login-LAT-Service
+ 0-1 0-1 0 0 35 Login-LAT-Node
+ 0-1 0-1 0 0 36 Login-LAT-Group
+ 0 0-1 0 0 37 Framed-AppleTalk-Link
+ 0 0+ 0 0 38 Framed-AppleTalk-Network
+ 0 0-1 0 0 39 Framed-AppleTalk-Zone
+ 0-1 0 0 0 60 CHAP-Challenge
+ 0-1 0 0 0 61 NAS-Port-Type
+ 0-1 0-1 0 0 62 Port-Limit
+ 0-1 0-1 0 0 63 Login-LAT-Port
+
+
+ Request Accept Reject Challenge # Attribute
+
+
+ [Note 1] An Access-Request MUST contain either a User-Password or a
+ CHAP-Password, and MUST NOT contain both.
+
+ The following table defines the meaning of the above table entries.
+
+ 0 This attribute MUST NOT be present in packet.
+ 0+ Zero or more instances of this attribute MAY be present in packet.
+ 0-1 Zero or one instance of this attribute MAY be present in packet.
+ 1 Exactly one instance of this attribute MUST be present in packet.
+
+6. Examples
+
+ A few examples are presented to illustrate the flow of packets and
+ use of typical attributes. These examples are not intended to be
+ exhaustive, many others are possible.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 59]
+
+RFC 2138 RADIUS April 1997
+
+
+6.1. User Telnet to Specified Host
+
+ The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
+ RADIUS Server for a user named nemo logging in on port 3.
+
+ Code = 1 (Access-Request)
+ ID = 0
+ Length = 56
+ Request Authenticator = {16 octet random number}
+ Attributes:
+ User-Name = "nemo"
+ User-Password = {16 octets of Password padded at end with nulls,
+ XORed with MD5(shared secret|Request Authenticator)}
+ NAS-IP-Address = 192.168.1.16
+ NAS-Port = 3
+
+ The RADIUS server authenticates nemo, and sends an Access-Accept UDP
+ packet to the NAS telling it to telnet nemo to host 192.168.1.3.
+
+ Code = 2 (Access-Accept)
+ ID = 0 (same as in Access-Request)
+ Length = 38
+ Response Authenticator = {16-octet MD-5 checksum of the code (2),
+ id (0), Length (38), the Request Authenticator from
+ above, the attributes in this reply, and the shared
+ secret}
+ Attributes:
+ Service-Type = Login-User
+ Login-Service = Telnet
+ Login-Host = 192.168.1.3
+
+6.2. Framed User Authenticating with CHAP
+
+ The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
+ RADIUS Server for a user named flopsy logging in on port 20 with PPP,
+ authenticating using CHAP. The NAS sends along the Service-Type and
+ Framed-Protocol attributes as a hint to the RADIUS server that this
+ user is looking for PPP, although the NAS is not required to do so.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 60]
+
+RFC 2138 RADIUS April 1997
+
+
+ Code = 1 (Access-Request)
+ ID = 1
+ Length = 71
+ Request Authenticator = {16 octet random number also used as
+ CHAP challenge}
+ Attributes:
+ User-Name = "flopsy"
+ CHAP-Password = {1 octet CHAP ID followed by 16 octet
+ CHAP response}
+ NAS-IP-Address = 192.168.1.16
+ NAS-Port = 20
+ Service-Type = Framed-User
+ Framed-Protocol = PPP
+
+ The RADIUS server authenticates flopsy, and sends an Access-Accept
+ UDP packet to the NAS telling it to start PPP service and assign an
+ address for the user out of its dynamic address pool.
+
+ Code = 2 (Access-Accept)
+ ID = 1 (same as in Access-Request)
+ Length = 56
+ Response Authenticator = {16-octet MD-5 checksum of the code (2),
+ id (1), Length (56), the Request Authenticator from
+ above, the attributes in this reply, and the shared
+ secret}
+ Attributes:
+ Service-Type = Framed-User
+ Framed-Protocol = PPP
+ Framed-IP-Address = 255.255.255.254
+ Framed-Routing = None
+ Framed-Compression = 1 (VJ TCP/IP Header Compression)
+ Framed-MTU = 1500
+
+6.3. User with Challenge-Response card
+
+ The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
+ RADIUS Server for a user named mopsy logging in on port 7.
+
+ Code = 1 (Access-Request)
+ ID = 2
+ Length = 57
+ Request Authenticator = {16 octet random number}
+ Attributes:
+ User-Name = "mopsy"
+ User-Password = {16 octets of Password padded at end with nulls,
+ XORed with MD5(shared secret|Request Authenticator)}
+ NAS-IP-Address = 192.168.1.16
+ NAS-Port = 7
+
+
+
+Rigney, et. al. Standards Track [Page 61]
+
+RFC 2138 RADIUS April 1997
+
+
+ The RADIUS server decides to challenge mopsy, sending back a
+ challenge string and looking for a response. The RADIUS server
+ therefore and sends an Access-Challenge UDP packet to the NAS.
+
+ Code = 11 (Access-Challenge}
+ ID = 2 (same as in Access-Request)
+ Length = 78
+ Response Authenticator = {16-octet MD-5 checksum of the code (11),
+ id (2), length (78), the Request Authenticator from
+ above, the attributes in this reply, and the shared
+ secret}
+ Attributes:
+ Reply-Message = "Challenge 32769430. Enter response at prompt."
+ State = {Magic Cookie to be returned along with user's response;
+ in this example 8 octets of data}
+
+ The user enters his response, and the NAS send a new Access-Request
+ with that response, and includes the State Attribute.
+
+ Code = 1 (Access-Request)
+ ID = 3 (Note that this changes)
+ Length = 67
+ Request Authenticator = {NEW 16 octet random number}
+ Attributes:
+ User-Name = "mopsy"
+ User-Password = {16 octets of Response padded at end with
+ nulls, XORed with MD5 checksum of shared secret
+ plus above Request Authenticator}
+ NAS-IP-Address = 192.168.1.16
+ NAS-Port = 7
+ State = {Magic Cookie from Access-Challenge packet, unchanged}
+
+ The Response was incorrect, so the RADIUS server tells the NAS to
+ reject the login attempt.
+
+ Code = 3 (Access-Reject)
+ ID = 3 (same as in Access-Request)
+ Length = 20
+ Response Authenticator = {16-octet MD-5 checksum of the code (3),
+ id (3), length(20), the Request Authenticator from
+ above, the attributes in this reply if any, and the
+ shared secret}
+ Attributes:
+ (none, although a Reply-Message could be sent)
+
+
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 62]
+
+RFC 2138 RADIUS April 1997
+
+
+Security Considerations
+
+ Security issues are the primary topic of this document.
+
+ In practice, within or associated with each RADIUS 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. 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 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 [8], but such a mechanism is outside the scope of this
+ specification.
+
+ Other distribution methods are currently undergoing research and
+ experimentation. The SNMP Security document [8] also has an
+ excellent overview of threats to network protocols.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 63]
+
+RFC 2138 RADIUS April 1997
+
+
+References
+
+ [1] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm",
+ RFC 1321, MIT Laboratory for Computer Science, RSA Data
+ Security Inc., April 1992.
+
+ [2] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+ USC/Information Sciences Institute, August 1980.
+
+ [3] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
+ 1700, USC/Information Sciences Institute, October 1994.
+
+ [4] Kaufman, C., Perlman, R., and Speciner, M., "Network Security:
+ Private Communications in a Public World", Prentice Hall, March
+ 1995, ISBN 0-13-061466-1.
+
+ [5] Jacobson, V., "Compressing TCP/IP headers for low-speed serial
+ links", RFC 1144, Lawrence Berkeley Laboratory, February 1990.
+
+ [6] ISO 8859. International Standard -- Information Processing --
+ 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin
+ Alphabet No. 1, ISO 8859-1:1987.
+ <URL:http://www.iso.ch/cate/d16338.html>
+
+ [7] Sklower, K., Lloyd, B., McGregor, G., and Carr, D., "The PPP
+ Multilink Protocol (MP)", RFC 1717, University of California
+ Berkeley, Lloyd Internetworking, Newbridge Networks
+ Corporation, November 1994.
+
+ [8] Galvin, J., McCloghrie, K., and Davin, J., "SNMP Security
+ Protocols", RFC 1352, Trusted Information Systems, Inc., Hughes
+ LAN Systems, Inc., MIT Laboratory for Computer Science, July
+ 1992.
+
+ [9] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
+
+Acknowledgments
+
+ RADIUS was originally developed by Livingston Enterprises for their
+ PortMaster series of Network Access Servers.
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 64]
+
+RFC 2138 RADIUS April 1997
+
+
+Chair's Address
+
+ The working group can be contacted via the current chair:
+
+ Carl Rigney
+ Livingston Enterprises
+ 4464 Willow Road
+ Pleasanton, California 94588
+
+ Phone: +1 510 426 0770
+ EMail: cdr@livingston.com
+
+Authors' Addresses
+
+ Questions about this memo can also be directed to:
+
+ Carl Rigney
+ Livingston Enterprises
+ 4464 Willow Road
+ Pleasanton, California 94588
+
+ Phone: +1 510 426 0770
+ EMail: cdr@livingston.com
+
+ Allan C. Rubens
+ Merit Network, Inc.
+ 4251 Plymouth Road
+ Ann Arbor, Michigan 48105-2785
+
+ EMail: acr@merit.edu
+
+ William Allen Simpson
+ Daydreamer
+ Computer Systems Consulting Services
+ 1384 Fontaine
+ Madison Heights, Michigan 48071
+
+ EMail: wsimpson@greendragon.com
+
+ Steve Willens
+ Livingston Enterprises
+ 4464 Willow Road
+ Pleasanton, California 94588
+
+ EMail: steve@livingston.com
+
+
+
+
+
+
+Rigney, et. al. Standards Track [Page 65]
+
diff --git a/rfc/rfc2139.txt b/rfc/rfc2139.txt
new file mode 100644
index 0000000..88c5af8
--- /dev/null
+++ b/rfc/rfc2139.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+Network Working Group C. Rigney
+Request for Comments: 2139 Livingston
+Obsoletes: 2059 April 1997
+Category: Informational
+
+
+ RADIUS Accounting
+
+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
+
+ This document describes a protocol for carrying accounting
+ information between a Network Access Server and a shared Accounting
+ Server.
+
+Implementation Note
+
+ This memo documents the RADIUS Accounting protocol. There has been
+ some confusion in the assignment of port numbers for this protocol.
+ The early deployment of RADIUS Accounting was done using the
+ erroneously chosen port number 1646, which conflicts with the "sa-
+ msg-port" service. The officially assigned port number for RADIUS
+ Accounting is 1813.
+
+Table of Contents
+
+ 1. Introduction .......................................... 2
+ 1.1 Specification of Requirements ................... 3
+ 1.2 Terminology ..................................... 3
+ 2. Operation ............................................. 4
+ 3. Packet Format ......................................... 5
+ 4. Packet Types .......................................... 7
+ 4.1 Accounting-Request .............................. 7
+ 4.2 Accounting-Response ............................. 8
+ 5. Attributes ............................................ 10
+ 5.1 Acct-Status-Type ................................ 11
+ 5.2 Acct-Delay-Time ................................. 12
+ 5.3 Acct-Input-Octets ............................... 13
+ 5.4 Acct-Output-Octets .............................. 14
+ 5.5 Acct-Session-Id ................................. 14
+ 5.6 Acct-Authentic .................................. 15
+ 5.7 Acct-Session-Time ............................... 16
+ 5.8 Acct-Input-Packets .............................. 16
+
+
+
+Rigney Informational [Page 1]
+
+RFC 2139 RADIUS Accounting April 1997
+
+
+ 5.9 Acct-Output-Packets ............................. 17
+ 5.10 Acct-Terminate-Cause ............................ 18
+ 5.11 Acct-Multi-Session-Id ........................... 20
+ 5.12 Acct-Link-Count ................................. 21
+ 5.13 Table of Attributes ............................. 22
+ Security Considerations ...................................... 24
+ References ................................................... 24
+ Acknowledgements ............................................. 24
+ Chair's Address .............................................. 24
+ Author's Address ............................................. 25
+
+1. Introduction
+
+ Managing dispersed serial line and modem pools for large numbers of
+ users can create the need for significant administrative support.
+ Since modem pools are by definition a link to the outside world, they
+ require careful attention to security, authorization and accounting.
+ This can be best achieved by managing a single "database" of users,
+ which allows for authentication (verifying user name and password) as
+ well as configuration information detailing the type of service to
+ deliver to the user (for example, SLIP, PPP, telnet, rlogin).
+
+ The RADIUS (Remote Authentication Dial In User Service) document [4]
+ specifies the RADIUS protocol used for Authentication and
+ Authorization. This memo extends the use of the RADIUS protocol to
+ cover delivery of accounting information from the Network Access
+ Server (NAS) to a RADIUS accounting server.
+
+ Key features of RADIUS Accounting are:
+
+ Client/Server Model
+
+ A Network Access Server (NAS) operates as a client of the
+ RADIUS accounting server. The client is responsible for
+ passing user accounting information to a designated RADIUS
+ accounting server.
+
+ The RADIUS accounting server is responsible for receiving the
+ accounting request and returning a response to the client
+ indicating that it has successfully received the request.
+
+ The RADIUS accounting server can act as a proxy client to other
+ kinds of accounting servers.
+
+
+
+
+
+
+
+
+Rigney Informational [Page 2]
+
+RFC 2139 RADIUS Accounting April 1997
+
+
+ Network Security
+
+ Transactions between the client and RADIUS accounting server
+ are authenticated through the use of a shared secret, which is
+ never sent over the network.
+
+ Extensible Protocol
+
+ All transactions are comprised of variable length Attribute-
+ Length-Value 3-tuples. New attribute values can be added
+ without disturbing existing implementations of the protocol.
+
+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.
+
+1.2. Terminology
+
+ This document uses the following terms:
+
+ service The NAS provides a service to the dial-in user, such as PPP
+ or Telnet.
+
+
+
+
+
+
+
+
+
+
+Rigney Informational [Page 3]
+
+RFC 2139 RADIUS Accounting April 1997
+
+
+ session Each service provided by the NAS to a dial-in user
+ constitutes a session, with the beginning of the session
+ defined as the point where service is first provided and
+ the end of the session defined as the point where service
+ is ended. A user may have multiple sessions in parallel or
+ series if the NAS supports that, with each session
+ generating a separate start and stop accounting record with
+ its own Acct-Session-Id.
+
+ 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. Operation
+
+ When a client is configured to use RADIUS Accounting, at the start of
+ service delivery it will generate an Accounting Start packet
+ describing the type of service being delivered and the user it is
+ being delivered to, and will send that to the RADIUS Accounting
+ server, which will send back an acknowledgement that the packet has
+ been received. At the end of service delivery the client will
+ generate an Accounting Stop packet describing the type of service
+ that was delivered and optionally statistics such as elapsed time,
+ input and output octets, or input and output packets. It will send
+ that to the RADIUS Accounting server, which will send back an
+ acknowledgement that the packet has been received.
+
+ The Accounting-Request (whether for Start or Stop) is submitted to
+ the RADIUS accounting server via the network. It is recommended that
+ the client continue attempting to send the Accounting-Request packet
+ until it receives an acknowledgement, using some form of backoff. If
+ no response is returned within a length of time, the request is re-
+ sent a number of times. The client can also forward requests to an
+ alternate server or servers in the event that the primary server is
+ down or unreachable. An alternate server can be used either after a
+ number of tries to the primary server fail, or in a round-robin
+ fashion. Retry and fallback algorithms are the topic of current
+ research and are not specified in detail in this document.
+
+ The RADIUS accounting server MAY make requests of other servers in
+ order to satisfy the request, in which case it acts as a client.
+
+ If the RADIUS accounting server is unable to successfully record the
+ accounting packet it MUST NOT send an Accounting-Response
+ acknowledgment to the client.
+
+
+
+Rigney Informational [Page 4]
+
+RFC 2139 RADIUS Accounting April 1997
+
+
+3. Packet Format
+
+ Exactly one RADIUS Accounting packet is encapsulated in the UDP Data
+ field [1], where the UDP Destination Port field indicates 1813
+ (decimal).
+
+ When a reply is generated, the source and destination ports are
+ reversed.
+
+ This memo documents the RADIUS Accounting protocol. There has been
+ some confusion in the assignment of port numbers for this protocol.
+ The early deployment of RADIUS Accounting was done using the
+ erroneously chosen port number 1646, which conflicts with the "sa-
+ msg-port" service. The officially assigned port number for RADIUS
+ Accounting is 1813.
+
+ A summary of the RADIUS data 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 |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| |
+| Authenticator |
+| |
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Attributes ...
++-+-+-+-+-+-+-+-+-+-+-+-+-
+
+
+Code
+
+ The Code field is one octet, and identifies the type of RADIUS
+ packet. When a packet is received with an invalid Code field, it is
+ silently discarded.
+
+ RADIUS Accounting Codes (decimal) are assigned as follows:
+
+ 4 Accounting-Request
+ 5 Accounting-Response
+
+Identifier
+
+ The Identifier field is one octet, and aids in matching requests and
+ replies.
+
+
+
+Rigney Informational [Page 5]
+
+RFC 2139 RADIUS Accounting April 1997
+
+
+Length
+
+ The Length field is two octets. It indicates the length of the
+ packet including the Code, Identifier, Length, Authenticator and
+ Attribute fields. Octets outside the range of the Length field
+ should be treated as padding and should be ignored on reception. If
+ the packet is shorter than the Length field indicates, it should be
+ silently discarded. The minimum length is 20 and maximum length is
+ 4096.
+
+Authenticator
+
+ The Authenticator field is sixteen (16) octets. The most significant
+ octet is transmitted first. This value is used to authenticate the
+ messages between the client and RADIUS accounting server.
+
+Request Authenticator
+
+ In Accounting-Request Packets, the Authenticator value is a 16 octet
+ MD5 [3] checksum, called the Request Authenticator.
+
+ The NAS and RADIUS accounting server share a secret. The Request
+ Authenticator field in Accounting-Request packets contains a one- way
+ MD5 hash calculated over a stream of octets consisting of the Code +
+ Identifier + Length + 16 zero octets + request attributes + shared
+ secret (where + indicates concatenation). The 16 octet MD5 hash
+ value is stored in the Authenticator field of the Accounting-Request
+ packet.
+
+ Note that the Request Authenticator of an Accounting-Request can
+ not be done the same way as the Request Authenticator of a RADIUS
+ Access-Request, because there is no User-Password attribute in an
+ Accounting-Request.
+
+Response Authenticator
+
+ The Authenticator field in an Accounting-Response packet is called
+ the Response Authenticator, and contains a one-way MD5 hash
+ calculated over a stream of octets consisting of the Accounting-
+ Response Code, Identifier, Length, the Request Authenticator field
+ from the Accounting-Request packet being replied to, and the response
+ attributes if any, followed by the shared secret. The resulting 16
+ octet MD5 hash value is stored in the Authenticator field of the
+ Accounting-Response packet.
+
+
+
+
+
+
+
+Rigney Informational [Page 6]
+
+RFC 2139 RADIUS Accounting April 1997
+
+
+Attributes
+
+ Attributes may have multiple instances, in such a case the order of
+ attributes of the same type SHOULD be preserved. The order of
+ attributes of different types is not required to be preserved.
+
+4. Packet Types
+
+ The RADIUS packet type is determined by the Code field in the first
+ octet of the packet.
+
+4.1. Accounting-Request
+
+ Description
+
+ Accounting-Request packets are sent from a client (typically a
+ Network Access Server or its proxy) to a RADIUS accounting server,
+ and convey information used to provide accounting for a service
+ provided to a user. The client transmits a RADIUS packet with the
+ Code field set to 4 (Accounting-Request).
+
+ Upon receipt of an Accounting-Request, the server MUST transmit an
+ Accounting-Response reply if it successfully records the
+ accounting packet, and MUST NOT transmit any reply if it fails to
+ record the accounting packet.
+
+ Any attribute valid in a RADIUS Access-Request or Access-Accept
+ packet is valid in a RADIUS Accounting-Request packet, except that
+ the following attributes MUST NOT be present in an Accounting-
+ Request: User-Password, CHAP-Password, Reply-Message, State.
+ Either NAS-IP-Address or NAS-Identifier MUST be present in a
+ RADIUS Accounting-Request. It SHOULD contain a NAS-Port or NAS-
+ Port-Type attribute or both unless the service does not involve a
+ port or the NAS does not distinguish among its ports.
+
+ A summary of the Accounting-Request packet format is shown below.
+ The fields are transmitted from left to right.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney Informational [Page 7]
+
+RFC 2139 RADIUS Accounting April 1997
+
+
+ 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ | Request Authenticator |
+ | |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Attributes ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Code
+
+ 4 for Accounting-Request.
+
+ Identifier
+
+ The Identifier field MUST be changed whenever the content of the
+ Attributes field changes, and whenever a valid reply has been
+ received for a previous request. For retransmissions where the
+ contents are identical, the Identifier MUST remain unchanged.
+
+ Note that if Acct-Delay-Time is included in the attributes of an
+ Accounting-Request then the Acct-Delay-Time value will be updated
+ when the packet is retransmitted, changing the content of the
+ Attributes field and requiring a new Identifier and Request
+ Authenticator.
+
+ Request Authenticator
+
+ The Request Authenticator of an Accounting-Request contains a 16-
+ octet MD5 hash value calculated according to the method described
+ in "Request Authenticator" above.
+
+ Attributes
+
+ The Attributes field is variable in length, and contains a list of
+ Attributes.
+
+4.2. Accounting-Response
+
+ Description
+
+ Accounting-Response packets are sent by the RADIUS accounting
+ server to the client to acknowledge that the Accounting-Request
+ has been received and recorded successfully. If the Accounting-
+
+
+
+Rigney Informational [Page 8]
+
+RFC 2139 RADIUS Accounting April 1997
+
+
+ Request was recorded successfully then the RADIUS accounting
+ server MUST transmit a packet with the Code field set to 5
+ (Accounting-Response). On reception of an Accounting-Response by
+ the client, the Identifier field is matched with a pending
+ Accounting-Request. Invalid packets are silently discarded.
+
+ A RADIUS Accounting-Response is not required to have any
+ attributes in it.
+
+ A summary of the Accounting-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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ | Response Authenticator |
+ | |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Attributes ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Code
+
+ 5 for Accounting-Response.
+
+ Identifier
+
+ The Identifier field is a copy of the Identifier field of the
+ Accounting-Request which caused this Accounting-Response.
+
+ Response Authenticator
+
+ The Response Authenticator of an Accounting-Response contains a
+ 16-octet MD5 hash value calculated according to the method
+ described in "Response Authenticator" above.
+
+ Attributes
+
+ The Attributes field is variable in length, and contains a list of
+ zero or more Attributes.
+
+
+
+
+
+
+
+Rigney Informational [Page 9]
+
+RFC 2139 RADIUS Accounting April 1997
+
+
+5. Attributes
+
+ RADIUS Attributes carry the specific authentication, authorization
+ and accounting details for the request and response.
+
+ Some attributes MAY be included more than once. The effect of this
+ is attribute specific, and is specified in each attribute
+ description.
+
+ The end of the list of attributes is indicated by the Length of the
+ RADIUS packet.
+
+ A summary of the attribute 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 | Value ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ The Type field is one octet. Up-to-date values of the RADIUS Type
+ field are specified in the most recent "Assigned Numbers" RFC [2].
+ Values 192-223 are reserved for experimental use, values 224-240
+ are reserved for implementation-specific use, and values 241-255
+ are reserved and should not be used. This specification concerns
+ the following values:
+
+ 1-39 (refer to RADIUS document [4])
+ 40 Acct-Status-Type
+ 41 Acct-Delay-Time
+ 42 Acct-Input-Octets
+ 43 Acct-Output-Octets
+ 44 Acct-Session-Id
+ 45 Acct-Authentic
+ 46 Acct-Session-Time
+ 47 Acct-Input-Packets
+ 48 Acct-Output-Packets
+ 49 Acct-Terminate-Cause
+ 50 Acct-Multi-Session-Id
+ 51 Acct-Link-Count
+ 60+ (refer to RADIUS document [4])
+
+
+
+
+
+
+
+Rigney Informational [Page 10]
+
+RFC 2139 RADIUS Accounting April 1997
+
+
+ Length
+
+ The Length field is one octet, and indicates the length of this
+ attribute including the Type, Length and Value fields. If an
+ attribute is received in an Accounting-Request with an invalid
+ Length, the entire request should be silently discarded.
+
+ Value
+
+ The Value field is zero or more octets and contains information
+ specific to the attribute. The format and length of the Value
+ field is determined by the Type and Length fields.
+
+ The format of the value field is one of four data types.
+
+ string 0-253 octets
+
+ address 32 bit value, most significant octet first.
+
+ integer 32 bit value, most significant octet first.
+
+ time 32 bit value, most significant octet first -- seconds
+ since 00:00:00 GMT, January 1, 1970. The standard
+ Attributes do not use this data type but it is presented
+ here for possible use within Vendor-Specific attributes.
+
+5.1. Acct-Status-Type
+
+ Description
+
+ This attribute indicates whether this Accounting-Request marks the
+ beginning of the user service (Start) or the end (Stop).
+
+ It MAY be used by the client to mark the start of accounting (for
+ example, upon booting) by specifying Accounting-On and to mark the
+ end of accounting (for example, just before a scheduled reboot) by
+ specifying Accounting-Off.
+
+ A summary of the Acct-Status-Type attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+Rigney Informational [Page 11]
+
+RFC 2139 RADIUS Accounting April 1997
+
+
+ Type
+
+ 40 for Acct-Status-Type.
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets.
+
+ 1 Start
+ 2 Stop
+ 7 Accounting-On
+ 8 Accounting-Off
+
+5.2. Acct-Delay-Time
+
+ Description
+
+ This attribute indicates how many seconds the client has been
+ trying to send this record for, and can be subtracted from the
+ time of arrival on the server to find the approximate time of the
+ event generating this Accounting-Request. (Network transit time
+ is ignored.)
+
+ Note that changing the Acct-Delay-Time causes the Identifier to
+ change; see the discussion under Identifier above.
+
+ A summary of the Acct-Delay-Time attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 41 for Acct-Delay-Time.
+
+ Length
+
+ 6
+
+
+
+Rigney Informational [Page 12]
+
+RFC 2139 RADIUS Accounting April 1997
+
+
+ Value
+
+ The Value field is four octets.
+
+5.3. Acct-Input-Octets
+
+ Description
+
+ This attribute indicates how many octets have been received from
+ the port over the course of this service being provided, and can
+ only be present in Accounting-Request records where the Acct-
+ Status-Type is set to Stop.
+
+ A summary of the Acct-Input-Octets attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 42 for Acct-Input-Octets.
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets.
+
+5.4. Acct-Output-Octets
+
+ Description
+
+ This attribute indicates how many octets have been sent to the
+ port in the course of delivering this service, and can only be
+ present in Accounting-Request records where the Acct-Status-Type
+ is set to Stop.
+
+ A summary of the Acct-Output-Octets attribute format is shown below.
+ The fields are transmitted from left to right.
+
+
+
+
+Rigney Informational [Page 13]
+
+RFC 2139 RADIUS Accounting April 1997
+
+
+ 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 43 for Acct-Output-Octets.
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets.
+
+5.5. Acct-Session-Id
+
+ Description
+
+ This attribute is a unique Accounting ID to make it easy to match
+ start and stop records in a log file. The start and stop records
+ for a given session MUST have the same Acct-Session-Id. It is
+ strongly recommended that the Acct-Session-Id be a printable ASCII
+ string.
+
+ For example, one implementation uses a string with an 8-digit
+ upper case hexadecimal number, the first two digits increment on
+ each reboot (wrapping every 256 reboots) and the next 6 digits
+ counting from 0 for the first person logging in after a reboot up
+ to 2^24-1, about 16 million. Other encodings are possible.
+
+ A summary of the Acct-Session-Id attribute format is shown below.
+ The fields are transmitted from left to right.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney Informational [Page 14]
+
+RFC 2139 RADIUS Accounting April 1997
+
+
+ 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 | String ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 44 for Acct-Session-Id.
+
+ Length
+
+ >= 3
+
+ String
+
+ The String field SHOULD be a string of printable ASCII characters.
+
+5.6. Acct-Authentic
+
+ Description
+
+ This attribute MAY be included in an Accounting-Request to
+ indicate how the user was authenticated, whether by RADIUS, the
+ NAS itself, or another remote authentication protocol. Users who
+ are delivered service without being authenticated SHOULD NOT
+ generate Accounting records.
+
+ A summary of the Acct-Authentic attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 45 for Acct-Authentic.
+
+ Length
+
+ 6
+
+
+
+
+
+Rigney Informational [Page 15]
+
+RFC 2139 RADIUS Accounting April 1997
+
+
+ Value
+
+ The Value field is four octets.
+
+ 1 RADIUS
+ 2 Local
+ 3 Remote
+
+5.7. Acct-Session-Time
+
+ Description
+
+ This attribute indicates how many seconds the user has received
+ service for, and can only be present in Accounting-Request records
+ where the Acct-Status-Type is set to Stop.
+
+ A summary of the Acct-Session-Time attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 46 for Acct-Session-Time.
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets.
+
+5.8. Acct-Input-Packets
+
+ Description
+
+ This attribute indicates how many packets have been received from
+ the port over the course of this service being provided to a
+ Framed User, and can only be present in Accounting-Request records
+ where the Acct-Status-Type is set to Stop.
+
+
+
+
+Rigney Informational [Page 16]
+
+RFC 2139 RADIUS Accounting April 1997
+
+
+ A summary of the Acct-Input-packets attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 47 for Acct-Input-Packets.
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets.
+
+5.9. Acct-Output-Packets
+
+ Description
+
+ This attribute indicates how many packets have been sent to the
+ port in the course of delivering this service to a Framed User,
+ and can only be present in Accounting-Request records where the
+ Acct-Status-Type is set to Stop.
+
+ A summary of the Acct-Output-Packets attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 48 for Acct-Output-Packets.
+
+
+
+
+
+Rigney Informational [Page 17]
+
+RFC 2139 RADIUS Accounting April 1997
+
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets.
+
+5.10. Acct-Terminate-Cause
+
+ Description
+
+ This attribute indicates how the session was terminated, and can
+ only be present in Accounting-Request records where the Acct-
+ Status-Type is set to Stop.
+
+ A summary of the Acct-Terminate-Cause attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 49 for Acct-Terminate-Cause
+
+ Length
+
+ 6
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney Informational [Page 18]
+
+RFC 2139 RADIUS Accounting April 1997
+
+
+ Value
+
+ The Value field is four octets, containing an integer specifying
+ the cause of session termination, as follows:
+
+ 1 User Request
+ 2 Lost Carrier
+ 3 Lost Service
+ 4 Idle Timeout
+ 5 Session Timeout
+ 6 Admin Reset
+ 7 Admin Reboot
+ 8 Port Error
+ 9 NAS Error
+ 10 NAS Request
+ 11 NAS Reboot
+ 12 Port Unneeded
+ 13 Port Preempted
+ 14 Port Suspended
+ 15 Service Unavailable
+ 16 Callback
+ 17 User Error
+ 18 Host Request
+
+
+
+ The termination causes are as follows:
+
+ User Request User requested termination of service, for
+ example with LCP Terminate or by logging out.
+
+ Lost Carrier DCD was dropped on the port.
+
+ Lost Service Service can no longer be provided; for
+ example, user's connection to a host was
+ interrupted.
+
+ Idle Timeout Idle timer expired.
+
+ Session Timeout Maximum session length timer expired.
+
+ Admin Reset Administrator reset the port or session.
+
+ Admin Reboot Administrator is ending service on the NAS,
+ for example prior to rebooting the NAS.
+
+ Port Error NAS detected an error on the port which
+ required ending the session.
+
+
+
+Rigney Informational [Page 19]
+
+RFC 2139 RADIUS Accounting April 1997
+
+
+ NAS Error NAS detected some error (other than on the
+ port) which required ending the session.
+
+ NAS Request NAS ended session for a non-error reason not
+ otherwise listed here.
+
+ NAS Reboot The NAS ended the session in order to reboot
+ non-administratively ("crash").
+
+ Port Unneeded NAS ended session because resource usage fell
+ below low-water mark (for example, if a
+ bandwidth-on-demand algorithm decided that
+ the port was no longer needed).
+
+ Port Preempted NAS ended session in order to allocate the
+ port to a higher priority use.
+
+ Port Suspended NAS ended session to suspend a virtual
+ session.
+
+ Service Unavailable NAS was unable to provide requested service.
+
+ Callback NAS is terminating current session in order
+ to perform callback for a new session.
+
+ User Error Input from user is in error, causing
+ termination of session.
+
+ Host Request Login Host terminated session normally.
+
+5.11. Acct-Multi-Session-Id
+
+ Description
+
+ This attribute is a unique Accounting ID to make it easy to link
+ together multiple related sessions in a log file. Each session
+ linked together would have a unique Acct-Session-Id but the same
+ Acct-Multi-Session-Id. It is strongly recommended that the Acct-
+ Multi-Session-Id be a printable ASCII string.
+
+ A summary of the Acct-Session-Id attribute 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 | String ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+Rigney Informational [Page 20]
+
+RFC 2139 RADIUS Accounting April 1997
+
+
+ Type
+
+ 50 for Acct-Multi-Session-Id.
+
+ Length
+
+ >= 3
+
+ String
+
+ The String field SHOULD be a string of printable ASCII characters.
+
+5.12. Acct-Link-Count
+
+ Description
+
+ This attribute gives the count of links which are known to have
+ been in a given multilink session at the time the accounting
+ record is generated. The NAS MAY include the Acct-Link-Count
+ attribute in any Accounting-Request which might have multiple
+ links.
+
+ A summary of the Acct-Link-Count attribute format is show 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 51 for Acct-Link-Count.
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets, and contains the number of links
+ seen so far in this Multilink Session.
+
+
+
+
+
+
+Rigney Informational [Page 21]
+
+RFC 2139 RADIUS Accounting April 1997
+
+
+ It may be used to make it easier for an accounting server to know
+ when it has all the records for a given Multilink session. When
+ the number of Accounting-Requests received with Acct-Status-Type =
+ Stop and the same Acct-Multi-Session-Id and unique Acct-Session-
+ Id's equals the largest value of Acct-Link-Count seen in those
+ Accounting-Requests, all Stop Accounting-Requests for that
+ Multilink Session have been received.
+
+ An example showing 8 Accounting-Requests should make things
+ clearer. For clarity only the relevant attributes are shown, but
+ additional attributes containing accounting information will also
+ be present in the Accounting-Request.
+
+ Multi-Session-Id Session-Id Status-Type Link-Count
+ "10" "10" Start 1
+ "10" "11" Start 2
+ "10" "11" Stop 2
+ "10" "12" Start 3
+ "10" "13" Start 4
+ "10" "12" Stop 4
+ "10" "13" Stop 4
+ "10" "10" Stop 4
+
+5.13. Table of Attributes
+
+ The following table provides a guide to which attributes may be found
+ in Accounting-Request packets. No attributes should be found in
+ Accounting-Response packets except Proxy-State and possibly Vendor-
+ Specific.
+
+ # Attribute
+ 0-1 User-Name
+ 0 User-Password
+ 0 CHAP-Password
+ 0-1 NAS-IP-Address [5]
+ 0-1 NAS-Port
+ 0-1 Service-Type
+ 0-1 Framed-Protocol
+ 0-1 Framed-IP-Address
+ 0-1 Framed-IP-Netmask
+ 0-1 Framed-Routing
+ 0+ Filter-Id
+ 0-1 Framed-MTU
+ 0+ Framed-Compression
+ 0+ Login-IP-Host
+ 0-1 Login-Service
+ 0-1 Login-TCP-Port
+ 0 Reply-Message
+
+
+
+Rigney Informational [Page 22]
+
+RFC 2139 RADIUS Accounting April 1997
+
+
+ 0-1 Callback-Number
+ 0-1 Callback-Id
+ 0+ Framed-Route
+ 0-1 Framed-IPX-Network
+ 0 State
+ 0+ Class
+ 0+ Vendor-Specific
+ 0-1 Session-Timeout
+ 0-1 Idle-Timeout
+ 0-1 Termination-Action
+ 0-1 Called-Station-Id
+ 0-1 Calling-Station-Id
+ 0-1 NAS-Identifier [4]
+ 0+ Proxy-State
+ 0-1 Login-LAT-Service
+ 0-1 Login-LAT-Node
+ 0-1 Login-LAT-Group
+ 0-1 Framed-AppleTalk-Link
+ 0-1 Framed-AppleTalk-Network
+ 0-1 Framed-AppleTalk-Zone
+ 1 Acct-Status-Type
+ 0-1 Acct-Delay-Time
+ 0-1 Acct-Input-Octets
+ 0-1 Acct-Output-Octets
+ 1 Acct-Session-Id
+ 0-1 Acct-Authentic
+ 0-1 Acct-Session-Time
+ 0-1 Acct-Input-Packets
+ 0-1 Acct-Output-Packets
+ 0-1 Acct-Terminate-Cause
+ 0+ Acct-Multi-Session-Id
+ 0+ Acct-Link-Count
+ 0 CHAP-Challenge
+ 0-1 NAS-Port-Type
+ 0-1 Port-Limit
+ 0-1 Login-LAT-Port
+
+
+ [5] An Accounting-Request MUST contain either a NAS-IP-Address or a
+ NAS-Identifier, and it is permitted (but not recommended) for it to
+ contain both.
+
+ The following table defines the above table entries.
+
+ 0 This attribute MUST NOT be present
+ 0+ Zero or more instances of this attribute MAY be present.
+ 0-1 Zero or one instance of this attribute MAY be present.
+ 1 Exactly one instance of this attribute MUST be present.
+
+
+
+Rigney Informational [Page 23]
+
+RFC 2139 RADIUS Accounting April 1997
+
+
+Security Considerations
+
+ Security issues are briefly discussed in sections concerning the
+ authenticator included in accounting requests and responses, using a
+ shared secret which is never sent over the network.
+
+References
+
+ [1] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+ USC/Information Sciences Institute, August 1980.
+
+ [2] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC
+ 1700, USC/Information Sciences Institute, October 1994.
+
+ [3] Rivest, R., and Dusse, S., "The MD5 Message-Digest Algorithm",
+ RFC 1321, MIT Laboratory for Computer Science, RSA Data
+ Security Inc., April 1992.
+
+ [4] Rigney, C., Rubens, A., Simpson, W., and Willens, S., "Remote
+ Authentication Dial In User Service (RADIUS)", RFC 2138,
+ April 1997.
+
+Acknowledgments
+
+ RADIUS and RADIUS Accounting were originally developed by Livingston
+ Enterprises for their PortMaster series of Network Access Servers.
+
+Chair's Address
+
+ The RADIUS working group can be contacted via the current chair:
+
+ Carl Rigney
+ Livingston Enterprises
+ 4464 Willow Road
+ Pleasanton, California 94588
+
+ Phone: +1 510 426 0770
+ EMail: cdr@livingston.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney Informational [Page 24]
+
+RFC 2139 RADIUS Accounting April 1997
+
+
+Author's Address
+
+ Questions about this memo can also be directed to:
+
+ Carl Rigney
+ Livingston Enterprises
+ 4464 Willow Road
+ Pleasanton, California 94588
+
+ EMail: cdr@livingston.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney Informational [Page 25]
+
diff --git a/rfc/rfc2284.txt b/rfc/rfc2284.txt
new file mode 100644
index 0000000..9940562
--- /dev/null
+++ b/rfc/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/rfc/rfc2433.txt b/rfc/rfc2433.txt
new file mode 100644
index 0000000..3536e72
--- /dev/null
+++ b/rfc/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/rfc/rfc2548.txt b/rfc/rfc2548.txt
new file mode 100644
index 0000000..35c83c3
--- /dev/null
+++ b/rfc/rfc2548.txt
@@ -0,0 +1,2299 @@
+
+
+
+
+
+
+Network Working Group G. Zorn
+Request for Comments: 2548 Microsoft Corporation
+Category: Informational March 1999
+
+
+ Microsoft Vendor-specific RADIUS Attributes
+
+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.
+
+Abstract
+
+ This document describes the set of Microsoft vendor-specific RADIUS
+ attributes. These attributes are designed to support Microsoft
+ proprietary dial-up protocols and/or provide support for features
+ which is not provided by the standard RADIUS attribute set [3]. It
+ is expected that this memo will be updated whenever Microsoft defines
+ a new vendor-specific attribute, since its primary purpose is to
+ provide an open, easily accessible reference for third-parties
+ wishing to interoperate with Microsoft products.
+
+1. 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].
+
+2. Attributes
+
+ The following sections describe sub-attributes which may be
+ transmitted in one or more RADIUS attributes of type Vendor-Specific
+ [3]. More than one sub-attribute MAY be transmitted in a single
+ Vendor-Specific Attribute; if this is done, the sub-attributes SHOULD
+ be packed as a sequence of Vendor-Type/Vendor-Length/Value triples
+ following the inital Type, Length and Vendor-ID fields. The Length
+ field of the Vendor-Specific Attribute MUST be set equal to the sum
+ of the Vendor-Length fields of the sub-attributes contained in the
+ Vendor-Specific Attribute, plus six. The Vendor-ID field of the
+ Vendor-Specific Attribute(s) MUST be set to decimal 311 (Microsoft).
+
+
+
+
+
+Zorn Informational [Page 1]
+
+RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
+
+
+2.1. Attributes for Support of MS-CHAP Version 1
+
+2.1.1. Introduction
+
+ Microsoft created Microsoft Challenge-Handshake Authentication
+ Protocol (MS-CHAP) [4] to authenticate remote Windows workstations,
+ providing the functionality to which LAN-based users are accustomed.
+ Where possible, MS-CHAP is consistent with standard CHAP [5], and the
+ differences are easily modularized. 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 Windows NT 3.5, 3.51 and 4.0,
+ Microsoft Windows95, and Microsoft LAN Manager 2.x networking
+ products. The MS-CHAP format does not require the authenticator
+ to store a clear-text or reversibly encrypted password.
+
+ * MS-CHAP provides an authenticator-controlled authentication
+ retry mechanism.
+
+ * MS-CHAP provides an authenticator-controlled password changing
+ mechanism.
+
+ * MS-CHAP defines an extended set of reason-for-failure codes,
+ returned in the Failure packet Message field.
+
+ The attributes defined in this section reflect these differences.
+
+2.1.2. MS-CHAP-Challenge
+
+ Description
+
+ This Attribute contains the challenge sent by a NAS to a Microsoft
+ Challenge-Handshake Authentication Protocol (MS-CHAP) user. It
+ MAY be used in both Access-Request and Access-Challenge packets.
+
+ A summary of the MS-CHAP-Challenge Attribute format is shown below.
+ The fields are transmitted from left to right.
+
+
+
+
+
+
+
+
+
+
+Zorn Informational [Page 2]
+
+RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor-Type | Vendor-Length | String...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Vendor-Type
+ 11 for MS-CHAP-Challenge.
+
+ Vendor-Length
+ > 2
+
+ String
+ The String field contains the MS-CHAP challenge.
+
+2.1.3. MS-CHAP-Response
+
+ Description
+
+ This Attribute contains the response value provided by a PPP
+ Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP)
+ user in response to the challenge. It is only used in Access-
+ Request packets.
+
+ A summary of the MS-CHAP-Response Attribute format is shown below.
+ The fields are transmitted from left to right.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zorn Informational [Page 3]
+
+RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor-Type | Vendor-Length | Ident | Flags |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | LM-Response
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ LM-Response (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ LM-Response (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ LM-Response (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ LM-Response (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ LM-Response(cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | NT-Response
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ NT-Response (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ NT-Response (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ NT-Response (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ NT-Response (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ NT-Response (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Vendor-Type
+ 1 for MS-CHAP-Response.
+
+ Vendor-Length
+ 52
+
+ Ident
+ Identical to the PPP CHAP Identifier.
+
+ Flags
+ The Flags field is one octet in length. If the Flags field is one
+ (0x01), the NT-Response field is to be used in preference to the
+ LM-Response field for authentication. The LM-Response field MAY
+ still be used (if non-empty), but the NT-Response SHOULD be tried
+ first. If it is zero, the NT-Response field MUST be ignored and
+ the LM-Response field used.
+
+
+
+
+
+Zorn Informational [Page 4]
+
+RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
+
+
+ LM-Response
+ The LM-Response field is 24 octets in length and holds an encoded
+ function of the password and the received challenge. If this
+ field is empty, it SHOULD be zero-filled.
+
+ NT-Response
+
+ The NT-Response field is 24 octets in length and holds an encoded
+ function of the password and the received challenge. If this
+ field is empty, it SHOULD be zero-filled.
+
+2.1.4. MS-CHAP-Domain
+
+ Description
+
+ The MS-CHAP-Domain Attribute indicates the Windows NT domain in
+ which the user was authenticated. It MAY be included in both
+ Access-Accept and Accounting-Request packets.
+
+ A summary of the MS-CHAP-Domain Attribute format is given below. The
+ fields are transmitted 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor-Type | Vendor-Length | Ident | String...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Vendor-Type
+ 10 for MS-CHAP-Domain.
+
+ Vendor-Length
+ > 3
+
+ Ident
+ The Ident field is one octet and aids in matching requests and
+ replies.
+
+ String
+ This field contains the name in ASCII of the Windows NT domain in
+ which the user was authenticated.
+
+
+
+
+
+
+
+
+
+
+Zorn Informational [Page 5]
+
+RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
+
+
+2.1.5. MS-CHAP-Error
+
+ Description
+
+ The MS-CHAP-Error Attribute contains error data related to the
+ preceding MS-CHAP exchange. This Attribute may be used in both
+ MS-CHAP-V1 and MS-CHAP-V2 (see below) exchanges. It is only used
+ in Access-Reject packets.
+
+ A summary of the MS-CHAP-Error Attribute format is given below. The
+ fields are transmitted 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor-Type | Vendor-Length | Ident | String...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Vendor-Type
+ 2 for MS-CHAP-Error.
+
+ Vendor-Length
+ > 3
+
+ Ident
+ The Ident field is one octet and aids in matching requests and
+ replies.
+
+ String
+ This field contains specially formatted ASCII text, which is
+ interpreted by the authenticating peer.
+
+2.1.6. MS-CHAP-CPW-1
+
+ Description
+
+ This Attribute allows the user to change their password if it has
+ expired. This Attribute is only used in Access-Request packets, and
+ should only be included if an MS-CHAP-Error attribute was included in
+ the immediately preceding Access-Reject packet, the String field of
+ the MS-CHAP-Error attribute indicated that the user password had
+ expired, and the MS-CHAP version is less than 2.
+
+ A summary of the MS-CHAP-CPW-1 Attribute format is shown below. The
+ fields are transmitted from left to right.
+
+
+
+
+
+
+Zorn Informational [Page 6]
+
+RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor-Type | Vendor-Length | Code | Ident |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | LM-Old-Password
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ LM-Old-Password (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ LM-Old-Password (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ LM-Old-Password (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | LM-New-Password
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ LM-New-Password (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ LM-New-Password (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ LM-New-Password (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | NT-Old-Password
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ NT-Old-Password (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ NT-Old-Password (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ NT-Old-Password (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | NT-New-Password
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ NT-New-Password (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ NT-New-Password (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ NT-New-Password (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | New-LM-Password-Length | Flags |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Vendor-Type
+ 3 for MS-CHAP-PW-1
+
+ Vendor-Length
+ 72
+
+ Code
+ The Code field is one octet in length. Its value is always 5.
+
+
+
+Zorn Informational [Page 7]
+
+RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
+
+
+ Ident
+ The Ident field is one octet and aids in matching requests and
+ replies.
+
+ LM-Old-Password
+ The LM-Old-Password field is 16 octets in length. It contains the
+ encrypted Lan Manager hash of the old password.
+
+ LM-New-Password
+ The LM-New-Password field is 16 octets in length. It contains the
+ encrypted Lan Manager hash of the new password.
+
+ NT-Old-Password
+ The NT-Old-Password field is 16 octets in length. It contains the
+ encrypted Lan Manager hash of the old password.
+
+ NT-New-Password
+ The NT-New-Password field is 16 octets in length. It contains the
+ encrypted Lan Manager hash of the new password.
+
+ New-LM-Password-Length
+ The New-LM-Password-Length field is two octets in length and
+ contains the length in octets of the new LAN Manager-compatible
+ password.
+
+ Flags
+ The Flags field is two octets in length. If the least significant
+ bit of the Flags field is one, this indicates that the NT-New-
+ Password and NT-Old-Password fields are valid and SHOULD be used.
+ Otherwise, the LM-New-Password and LM-Old-Password fields MUST be
+ used.
+
+2.1.7. MS-CHAP-CPW-2
+
+ Description
+
+ This Attribute allows the user to change their password if it has
+ expired. This Attribute is only used in Access-Request packets,
+ and should only be included if an MS-CHAP-Error attribute was
+ included in the immediately preceding Access-Reject packet, the
+ String field of the MS-CHAP-Error attribute indicated that the
+ user password had expired, and the MS-CHAP version is equal to 2.
+
+ A summary of the MS-CHAP-CPW-2 Attribute format is shown below. The
+ fields are transmitted from left to right.
+
+
+
+
+
+
+Zorn Informational [Page 8]
+
+RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor-Type | Vendor-Length | Code | Ident |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Old-NT-Hash
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Old-NT-Hash (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Old-NT-Hash (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Old-NT-Hash (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Old-LM-Hash
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Old-LM-Hash(cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Old-LM-Hash(cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Old-LM-Hash(cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | LM-Response
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ LM-Response (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ LM-Response (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ LM-Response (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ LM-Response (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ LM-Response (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | NT-Response
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++-+-+-+-+-+-+-+-+-+-+-+-+
+ NT-Response (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++-+-+-+-+-+-+-+-+-+-+-+
+ NT-Response (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ NT-Response (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ NT-Response (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ NT-Response (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Flags |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+Zorn Informational [Page 9]
+
+RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
+
+
+ Vendor-Type
+ 4 for MS-CHAP-PW-2
+
+ Vendor-Length
+ 86
+
+ Code
+ 6
+
+ Ident
+ The Ident field is one octet and aids in matching requests and
+ replies. The value of this field MUST be identical to that in the
+ Ident field in all instances of the MS-CHAP-LM-Enc-PW, MS-CHAP-NT-
+ Enc-PW and MS-CHAP-PW-2 attributes contained in a single Access-
+ Request packet.
+
+ Old-NT-Hash
+ The Old-NT-Hash field is 16 octets in length. It contains the old
+ Windows NT password hash encrypted with the new Windows NT
+ password hash.
+
+ Old-LM-Hash
+ The Old-LM-Hash field is 16 octets in length. It contains the old
+ Lan Manager password hash encrypted with the new Windows NT
+ password hash.
+
+ LM-Response
+ The LM-Response field is 24 octets in length and holds an encoded
+ function of the password and the received challenge. If this
+ field is empty, it SHOULD be zero-filled.
+
+ NT-Response
+ The NT-Response field is 24 octets in length and holds an encoded
+ function of the password and the received challenge. If this
+ field is empty, it SHOULD be zero-filled.
+
+ Flags
+ The Flags field is two octets in length. If the least significant
+ bit (bit 0) of this field is one, the NT-Response field is to be
+ used in preference to the LM-Response field for authentication.
+ The LM-Response field MAY still be used (if present), but the NT-
+ Response SHOULD be tried first. If least significant bit of the
+ field is zero, the NT-Response field MUST be ignored and the LM-
+ Response field used instead. If bit 1 of the Flags field is one,
+ the Old-LM-Hash field is valid and SHOULD be used. If this bit is
+ set, at least one instance of the MS-CHAP-LM-Enc-PW attribute MUST
+ be included in the packet.
+
+
+
+
+Zorn Informational [Page 10]
+
+RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
+
+
+2.1.8. MS-CHAP-LM-Enc-PW
+
+ Description
+
+ This Attribute contains the new Windows NT password encrypted with
+ the old LAN Manager password hash. The encrypted Windows NT
+ password is 516 octets in length; since this is longer than the
+ maximum lengtth of a RADIUS attribute, the password must be split
+ into several attibutes for transmission. A 2 octet sequence
+ number is included in the attribute to help preserve ordering of
+ the password fragments.
+
+ This Attribute is only used in Access-Request packets, in
+ conjunction with the MS-CHAP-CPW-2 attribute. It should only be
+ included if an MS-CHAP-Error attribute was included in the
+ immediately preceding Access-Reject packet, the String field of
+ the MS-CHAP-Error attribute indicated that the user password had
+ expired, and the MS-CHAP version is 2 or greater.
+
+ A summary of the MS-CHAP-LM-Enc-PW Attribute 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor-Type | Vendor-Length | Code | Ident |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Sequence-Number | String ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Vendor-Type
+ 5 for MS-CHAP-LM-Enc-PW
+
+ Vendor-Length
+ > 6
+
+ Code 6. Code is the same as for the MS-CHAP-PW-2 attribute.
+
+ Ident
+ The Ident field is one octet and aids in matching requests and
+ replies. The value of this field MUST be identical in all
+ instances of the MS-CHAP-LM-Enc-PW, MS-CHAP-NT-Enc-PW and MS-
+ CHAP-PW-2 attributes which are present in the same Access-Request
+ packet.
+
+
+
+
+
+
+
+Zorn Informational [Page 11]
+
+RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
+
+
+ Sequence-Number
+ The Sequence-Number field is two octets in length and indicates
+ which "chunk" of the encrypted password is contained in the
+ following String field.
+
+ String The String field contains a portion of the encrypted password.
+
+2.2. MS-CHAP-NT-Enc-PW
+
+ Description
+
+ This Attribute contains the new Windows NT password encrypted with
+ the old Windows NT password hash. The encrypted Windows NT
+ password is 516 octets in length; since this is longer than the
+ maximum lengtth of a RADIUS attribute, the password must be split
+ into several attibutes for transmission. A 2 octet sequence
+ number is included in the attribute to help preserve ordering of
+ the password fragments.
+
+ This Attribute is only used in Access-Request packets, in conjunc-
+ tion with the MS-CHAP-CPW-2 and MS-CHAP2-CPW attributes. It
+ should only be included if an MS-CHAP-Error attribute was included
+ in the immediately preceding Access-Reject packet, the String
+ field of the MS-CHAP-Error attribute indicated that the user
+ password had expired, and the MS-CHAP version is 2 or greater.
+
+ A summary of the MS-CHAP-NT-Enc-PW Attribute 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor-Type | Vendor-Length | Code | Ident |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Sequence-Number | String ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Vendor-Type
+ 6 for MS-CHAP-NT-Enc-PW
+
+ Vendor-Length
+ > 6
+
+ Code
+ 6. Code is the same as for the MS-CHAP-PW-2 attribute.
+
+
+
+
+
+
+Zorn Informational [Page 12]
+
+RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
+
+
+ Ident
+ The Ident field is one octet and aids in matching requests and
+ replies. The value of this field MUST be identical in all
+ instances of the MS-CHAP-LM-Enc-PW, MS-CHAP-NT-Enc-PW and MS-
+ CHAP-PW-2 attributes which are present in the same Access-Request
+ packet.
+
+ Sequence-Number
+ The Sequence-Number field is two octets in length and indicates
+ which "chunk" of the encrypted password is contained in the
+ following String field.
+
+ String
+ The String field contains a portion of the encrypted password.
+
+2.3. Attributes for Support of MS-CHAP Version 2
+
+2.3.1. Introduction
+
+ This section describes RADIUS attributes supporting version two of
+ Microsoft's PPP CHAP dialect (MS-CHAP-V2) [14]. MS-CHAP-V2 is
+ similar to, but incompatible with, MS-CHAP version one (MS-CHAP-V1)
+ [4]. Certain protocol fields have been deleted or reused but with
+ different semantics. Where possible, MS-CHAP-V2 is consistent with
+ both MS-CHAP-V1 and standard CHAP [1]. 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.
+
+
+
+Zorn Informational [Page 13]
+
+RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
+
+
+ The attributes defined in this section reflect these differences.
+
+2.3.2. MS-CHAP2-Response
+
+ Description
+
+ This Attribute contains the response value provided by an MS-
+ CHAP-V2 peer in response to the challenge. It is only used in
+ Access-Request packets.
+
+ A summary of the MS-CHAP2-Response Attribute 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor-Type | Vendor-Length | Ident | Flags |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Peer-Challenge
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Peer-Challenge (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Peer-Challenge (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Peer-Challenge (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Reserved
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Reserved (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Response
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Response (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Response (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Response (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Response (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Response (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Vendor-Type
+ 25 for MS-CHAP2-Response.
+
+ Vendor-Length
+ 52
+
+
+
+Zorn Informational [Page 14]
+
+RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
+
+
+ Ident
+ Identical to the PPP MS-CHAP v2 Identifier.
+
+ Flags
+ The Flags field is one octet in length. It is reserved for future
+ use and MUST be zero.
+
+ Peer-Challenge
+ The Peer-Challenge field is a 16-octet random number.
+
+ Reserved
+ This field is reserved for future use and MUST be zero.
+
+ Response
+ The Response field is 24 octets in length and holds an encoded
+ function of the password, the Peer-Challenge field and the
+ received challenge.
+
+2.3.3. MS-CHAP2-Success
+
+ Description
+
+ This Attribute contains a 42-octet authenticator response string.
+ This string MUST be included in the Message field of the MS-CHAP-
+ V2 Success packet sent from the NAS to the peer. This Attribute
+ is only used in Access-Accept packets.
+
+ A summary of the MS-CHAP2-Success Attribute 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor-Type | Vendor-Length | Ident | String...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Vendor-Type
+ 26 for MS-CHAP2-Success.
+
+ Vendor-Length
+ 45
+
+ Ident
+ Identical to the PPP MS-CHAP v2 Identifier.
+
+ String
+ The 42-octet authenticator string (see above).
+
+
+
+
+Zorn Informational [Page 15]
+
+RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
+
+
+2.3.4. MS-CHAP2-CPW
+
+ Description
+
+ This Attribute allows the user to change their password if it has
+ expired. This Attribute is only used in conjunction with the MS-
+ CHAP-NT-Enc-PW attribute in Access-Request packets, and should
+ only be included if an MS-CHAP-Error attribute was included in the
+ immediately preceding Access-Reject packet, the String field of
+ the MS-CHAP-Error attribute indicated that the user password had
+ expired, and the MS-CHAP version is equal to 3.
+
+ A summary of the MS-CHAP-CPW-2 Attribute format is shown below. The
+ fields are transmitted from left to right.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zorn Informational [Page 16]
+
+RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor-Type | Vendor-Length | Code | Ident |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Encrypted-Hash
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Encrypted-Hash (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Encrypted-Hash (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Encrypted-Hash (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Peer-Challenge
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Peer-Challenge (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Peer-Challenge (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Peer-Challenge (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Peer-Challenge (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Peer-Challenge (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | NT-Response
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++-+-+-+-+-+-+-+-+-+-+-+-+
+ NT-Response (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++-+-+-+-+-+-+-+-+-+-+-+
+ NT-Response (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ NT-Response (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ NT-Response (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ NT-Response (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Flags |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Vendor-Type
+ 27 for MS-CHAP2-PW
+
+ Vendor-Length
+ 70
+
+ Code
+ 7
+
+
+
+Zorn Informational [Page 17]
+
+RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
+
+
+ Ident
+ The Ident field is one octet and aids in matching requests and
+ replies. The value of this field MUST be identical to that in the
+ Ident field in all instances of the MS-CHAP-NT-Enc-PW contained in
+ the Access-Request packet.
+
+ Encrypted-Hash
+ The Encrypted-Hash field is 16 octets in length. It contains the
+ old Windows NT password hash encrypted with the new Windows NT
+ password hash.
+
+ NT-Response
+ The NT-Response field is 24 octets in length and holds an encoded
+ function of the new password, the Peer-Challenge field and the
+ received challenge.
+
+ Flags
+ The Flags field is two octets in length. This field is reserved
+ for future use and MUST be zero.
+
+2.4. Attributes for MPPE Support
+
+ This section describes a set of Attributes designed to support the
+ use of Microsoft Point-to-Point Encryption (MPPE) [6] in dial-up
+ networks. MPPE is a means of representing Point to Point Protocol
+ (PPP) [7] packets in a encrypted form. MPPE uses the RSA RC4 [8]
+ algorithm for encryption. 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. MPPE is negotiated within
+ option 18 in the PPP Compression Control Protocol (CCP)[9], [10].
+
+2.4.1. MS-CHAP-MPPE-Keys
+
+ Description
+
+ The MS-CHAP-MPPE-Keys Attribute contains two session keys for use
+ by the Microsoft Point-to-Point Encryption Protocol (MPPE). This
+ Attribute is only included in Access-Accept packets.
+
+ A summary of the MS-CHAP-MPPE-Keys Attribute format is given below.
+ The fields are transmitted left to right.
+
+
+
+
+
+
+
+
+
+
+Zorn Informational [Page 18]
+
+RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor-Type | Vendor-Length | Keys
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Keys (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Keys (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Keys (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Keys (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Keys (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Keys (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Keys (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Keys (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Vendor-Type
+ 12 for MS-CHAP-MPPE-Keys.
+
+ Vendor-Length
+ 34
+
+ Keys
+ The Keys field consists of two logical sub-fields: the LM-Key and
+ the NT-Key. The LM-Key is eight octets in length and contains the
+ first eight bytes of the output of the function LmPasswordHash(P,
+ This hash is constructed as follows: let the plain-text password
+ be represented by P.
+
+ The NT-Key sub-field is sixteen octets in length and contains the
+ first sixteen octets of the hashed Windows NT password. The
+ format of the plaintext Keys field is illustrated in the following
+ diagram:
+
+
+
+
+
+
+
+
+
+
+
+
+Zorn Informational [Page 19]
+
+RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | LM-Key
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ LM-Key (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | NT-Key
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ NT-Key (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ NT-Key (cont)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ NT-Key (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Padding
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Padding (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The Keys field MUST be encrypted by the RADIUS server using the
+ same method defined for the User-Password Attribute [3]. Padding
+ is required because the method referenced above requires the field
+ to be encrypted to be a multiple of sixteen octets in length.
+
+ Implementation Note
+ This attribute should only be returned in response to an
+ Access-Request packet containing MS-CHAP attributes.
+
+2.4.2. MS-MPPE-Send-Key
+
+ Description
+
+ The MS-MPPE-Send-Key Attribute contains a session key for use by
+ the Microsoft Point-to-Point Encryption Protocol (MPPE). As the
+ name implies, this key is intended for encrypting packets sent
+ from the NAS to the remote host. This Attribute is only included
+ in Access-Accept packets.
+
+ A summary of the MS-MPPE-Send-Key Attribute format is given below.
+ The fields are transmitted left to right.
+
+
+
+
+
+
+
+
+
+
+Zorn Informational [Page 20]
+
+RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor-Type | Vendor-Length | Salt
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ String...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Vendor-Type
+ 16 for MS-MPPE-Send-Key.
+
+ Vendor-Length
+ > 4
+
+ Salt
+ The Salt field is two octets in length and is used to ensure the
+ uniqueness of the keys used to encrypt each of the encrypted
+ attributes occurring in a given Access-Accept packet. The most
+ significant bit (leftmost) of the Salt field MUST be set (1). The
+ contents of each Salt field in a given Access-Accept packet MUST
+ be unique.
+
+ String
+ The plaintext String field consists of three logical sub-fields:
+ the Key-Length and Key sub-fields (both of which are required),
+ and the optional Padding sub-field. The Key-Length sub-field is
+ one octet in length and contains the length of the unencrypted Key
+ sub-field. The Key sub-field contains the actual encryption key.
+ If the combined length (in octets) of the unencrypted Key-Length
+ and Key sub-fields is not an even multiple of 16, then the Padding
+ sub-field MUST be present. If it is present, the length of the
+ Padding sub-field is variable, between 1 and 15 octets. The
+ String field MUST be encrypted as follows, prior to transmission:
+
+ Construct a plaintext version of the String field by concate-
+ nating the Key-Length and Key sub-fields. If necessary, pad
+ the resulting string until its length (in octets) is an even
+ multiple of 16. It is recommended that zero octets (0x00) be
+ used for padding. Call this plaintext P.
+
+ Call the shared secret S, the pseudo-random 128-bit Request
+ Authenticator (from the corresponding Access-Request packet) R,
+ and the contents of the Salt field A. Break P into 16 octet
+ chunks p(1), p(2)...p(i), where i = len(P)/16. Call the
+ ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C.
+ Intermediate values b(1), b(2)...c(i) are required. Encryption
+ is performed in the following manner ('+' indicates
+ concatenation):
+
+
+
+Zorn Informational [Page 21]
+
+RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
+
+
+ b(1) = MD5(S + R + A) c(1) = p(1) xor b(1) C = c(1)
+ b(2) = MD5(S + c(1)) c(2) = p(2) xor b(2) C = C + c(2)
+ . .
+ . .
+ . .
+ b(i) = MD5(S + c(i-1)) c(i) = p(i) xor b(i) C = C + c(i)
+
+ The resulting encrypted String field will contain
+ c(1)+c(2)+...+c(i).
+
+ On receipt, the process is reversed to yield the plaintext String.
+
+ Implementation Notes
+ It is possible that the length of the key returned may be larger
+ than needed for the encryption scheme in use. In this case, the
+ RADIUS client is responsible for performing any necessary
+ truncation.
+
+ This attribute MAY be used to pass a key from an external (e.g.,
+ EAP [15]) server to the RADIUS server. In this case, it may be
+ impossible for the external server to correctly encrypt the key,
+ since the RADIUS shared secret might be unavailable. The external
+ server SHOULD, however, return the attribute as defined above; the
+ Salt field SHOULD be zero-filled and padding of the String field
+ SHOULD be done. When the RADIUS server receives the attribute
+ from the external server, it MUST correctly set the Salt field and
+ encrypt the String field before transmitting it to the RADIUS
+ client. If the channel used to communicate the MS-MPPE-Send-Key
+ attribute is not secure from eavesdropping, the attribute MUST be
+ cryptographically protected.
+
+2.4.3. MS-MPPE-Recv-Key
+
+ Description
+
+ The MS-MPPE-Recv-Key Attribute contains a session key for use by
+ the Microsoft Point-to-Point Encryption Protocol (MPPE). As the
+ name implies, this key is intended for encrypting packets received
+ by the NAS from the remote host. This Attribute is only included
+ in Access-Accept packets.
+
+ A summary of the MS-MPPE-Recv-Key Attribute format is given below.
+ The fields are transmitted left to right.
+
+
+
+
+
+
+
+
+Zorn Informational [Page 22]
+
+RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor-Type | Vendor-Length | Salt
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ String...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Vendor-Type
+ 17 for MS-MPPE-Recv-Key.
+
+ Vendor-Length
+ > 4
+
+ Salt
+ The Salt field is two octets in length and is used to ensure the
+ uniqueness of the keys used to encrypt each of the encrypted
+ attributes occurring in a given Access-Accept packet. The most
+ significant bit (leftmost) of the Salt field MUST be set (1). The
+ contents of each Salt field in a given Access-Accept packet MUST
+ be unique.
+
+ String
+ The plaintext String field consists of three logical sub-fields:
+ the Key-Length and Key sub-fields (both of which are required),
+ and the optional Padding sub-field. The Key-Length sub-field is
+ one octet in length and contains the length of the unencrypted Key
+ sub-field. The Key sub-field contains the actual encryption key.
+ If the combined length (in octets) of the unencrypted Key-Length
+ and Key sub-fields is not an even multiple of 16, then the Padding
+ sub-field MUST be present. If it is present, the length of the
+ Padding sub-field is variable, between 1 and 15 octets. The
+ String field MUST be encrypted as follows, prior to transmission:
+
+ Construct a plaintext version of the String field by
+ concatenating the Key-Length and Key sub-fields. If necessary,
+ pad the resulting string until its length (in octets) is an
+ even multiple of 16. It is recommended that zero octets (0x00)
+ be used for padding. Call this plaintext P.
+
+ Call the shared secret S, the pseudo-random 128-bit Request
+ Authenticator (from the corresponding Access-Request packet) R,
+ and the contents of the Salt field A. Break P into 16 octet
+ chunks p(1), p(2)...p(i), where i = len(P)/16. Call the
+ ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C.
+ Intermediate values b(1), b(2)...c(i) are required. Encryption
+ is performed in the following manner ('+' indicates
+ concatenation):
+
+
+
+Zorn Informational [Page 23]
+
+RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
+
+
+ b(1) = MD5(S + R + A) c(1) = p(1) xor b(1) C = c(1)
+ b(2) = MD5(S + c(1)) c(2) = p(2) xor b(2) C = C + c(2)
+ . .
+ . .
+ . .
+ b(i) = MD5(S + c(i-1)) c(i) = p(i) xor b(i) C = C + c(i)
+
+ The resulting encrypted String field will contain
+ c(1)+c(2)+...+c(i).
+
+ On receipt, the process is reversed to yield the plaintext String.
+
+ Implementation Notes
+ It is possible that the length of the key returned may be larger
+ than needed for the encryption scheme in use. In this case, the
+ RADIUS client is responsible for performing any necessary
+ truncation.
+
+ This attribute MAY be used to pass a key from an external (e.g.,
+ EAP [15]) server to the RADIUS server. In this case, it may be
+ impossible for the external server to correctly encrypt the key,
+ since the RADIUS shared secret might be unavailable. The external
+ server SHOULD, however, return the attribute as defined above; the
+ Salt field SHOULD be zero-filled and padding of the String field
+ SHOULD be done. When the RADIUS server receives the attribute
+ from the external server, it MUST correctly set the Salt field and
+ encrypt the String field before transmitting it to the RADIUS
+ client. If the channel used to communicate the MS-MPPE-Recv-Key
+ attribute is not secure from eavesdropping, the attribute MUST be
+ cryptographically protected.
+
+2.4.4. MS-MPPE-Encryption-Policy
+
+ Description
+
+ The MS-MPPE-Encryption-Policy Attribute may be used to signify
+ whether the use of encryption is allowed or required. If the
+ Policy field is equal to 1 (Encryption-Allowed), any or none of
+ the encryption types specified in the MS-MPPE-Encryption-Types
+ Attribute MAY be used. If the Policy field is equal to 2
+ (Encryption-Required), any of the encryption types specified in
+ the MS-MPPE-Encryption-Types Attribute MAY be used, but at least
+ one MUST be used.
+
+ A summary of the MS-MPPE-Encryption-Policy Attribute format is given
+ below. The fields are transmitted left to right.
+
+
+
+
+
+Zorn Informational [Page 24]
+
+RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor-Type | Vendor-Length | Policy
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Policy (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Vendor-Type
+ 7 for MS-MPPE-Encryption-Policy.
+
+ Vendor-Length
+ 6
+
+ Policy
+ The Policy field is 4 octets in length. Defined values are:
+
+ 1 Encryption-Allowed 2 Encryption-Required
+
+2.4.5. MS-MPPE-Encryption-Types
+
+ Description
+
+ The MS-MPPE-Encryption-Types Attribute is used to signify the
+ types of encryption available for use with MPPE. It is a four
+ octet integer that is interpreted as a string of bits.
+
+ A summary of the MS-MPPE-Encryption-Policy Attribute format is given
+ below. The fields are transmitted 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor-Type | Vendor-Length | Types
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Types (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Vendor-Type
+ 8 for MS-MPPE-Encryption-Types.
+
+ Vendor-Length
+ 6
+
+ Policy
+ The Types field is 4 octets in length. The following diagram
+ illustrates the Types field.
+
+
+
+
+Zorn Informational [Page 25]
+
+RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |S|L| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ If the L bit is set, RC4[5] encryption using a 40-bit key is
+ allowed. If the S bit is set, RC4 encryption using a 128-bit key
+ is allowed. If both the L and S bits are set, then either 40- or
+ 128-bit keys may be used with the RC4 algorithm.
+
+2.5. Attributes for BAP Support
+
+ This section describes a set of vendor-specific RADIUS attributes
+ designed to support the dynamic control of bandwidth allocation in
+ multilink PPP [11]. Attributes are defined that specify whether use
+ of the PPP Bandwidth Allocation Protocol (BAP) [12] is allowed or
+ required on incoming calls, the level of line capacity (expressed as
+ a percentage) below which utilization must fall before a link is
+ eligible to be dropped, and the length of time (in seconds) that a
+ link must be under-utilized before it is dropped.
+
+2.5.1. MS-BAP-Usage
+
+ Description
+
+ This Attribute describes whether the use of BAP is allowed,
+ disallowed or required on new multilink calls. It MAY be used in
+ Access-Accept packets.
+
+ A summary of the MS-BAP-Usage Attribute 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor-Type | Vendor-Length | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Vendor-Type
+ 13 for MS-BAP-Usage.
+
+ Vendor-Length
+ 6
+
+
+
+
+
+Zorn Informational [Page 26]
+
+RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
+
+
+ Value
+ The Value field is four octets.
+
+ 0 BAP usage not allowed
+ 1 BAP usage allowed
+ 2 BAP usage required
+
+2.5.2. MS-Link-Utilization-Threshold
+
+ Description
+
+ This Attribute represents the percentage of available bandwidth
+ utilization below which the link must fall before the link is
+ eligible for termination. Permissible values for the MS-Link-
+ Utilization-Threshold Attribute are in the range 1-100, inclusive.
+ It is only used in Access-Accept packets.
+
+ A summary of the MS-Link-Utilization-Threshold Attribute 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor-Type | Vendor-Length | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Vendor-Type
+ 14 for MS-Link-Utilization-Threshold
+
+ Vendor-Length 6
+
+ Value The Value field is four octets in length and represents the
+ percentage of available bandwidth utilization below which the link
+ must fall before the link is eligible for termination.
+ Permissible values are in the range 1-100, inclusive.
+
+2.5.3. MS-Link-Drop-Time-Limit
+
+ Description
+
+ The MS-Link-Drop-Time-Limit Attribute indicates the length of time
+ (in seconds) that a link must be underutilized before it is
+ dropped. It MAY only be included in Access-Accept packets.
+
+ A summary of the MS-Link-Drop-Time-Limit Attribute format is given
+ below. The fields are transmitted left to right.
+
+
+
+Zorn Informational [Page 27]
+
+RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor-Type | Vendor-Length | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Vendor-Type
+ 15 for MS-Link-Drop-Time-Limit
+
+ Vendor-Length
+ 6
+
+ Value
+ The Value field represents the number of seconds that a link must
+ be underutilized (i.e., display bandwidth utilization below the
+ threshold specified in the MS-Link-Utilization-Threshold
+ Attribute) before the link is dropped.
+
+2.6. Attributes for ARAP Support
+
+ This section describes a set of Attributes designed to support the
+ Apple Remote Access Protocol (ARAP).
+
+2.6.1. MS-Old-ARAP-Password
+
+ Description
+
+ The MS-Old-ARAP-Password Attribute is used to transmit the old
+ ARAP password during an ARAP password change operation. It MAY be
+ included in Access-Request packets.
+
+ A summary of the MS-Old-ARAP-Password Attribute Attribute format is
+ given below. The fields are transmitted 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor-Type | Vendor-Length | String...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Vendor-Type
+ 19 for MS-Old-ARAP-Password Attribute
+
+ Vendor-Length
+ > 3
+
+
+
+
+Zorn Informational [Page 28]
+
+RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
+
+
+ String
+ The String field is one or more octets. It contains the old ARAP
+ password DES-encrypted using itself as the key.
+
+2.6.2. MS-New-ARAP-Password
+
+ Description
+
+ The MS-New-ARAP-Password Attribute is used to transmit the new
+ ARAP password during an ARAP password change operation. It MAY be
+ included in Access-Request packets.
+
+ A summary of the MS-New-ARAP-Password Attribute Attribute format is
+ given below. The fields are transmitted 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor-Type | Vendor-Length | String...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Vendor-Type
+ 20 for MS-New-ARAP-Password Attribute
+
+ Vendor-Length
+ > 3
+
+ String
+ The String field is one or more octets. It contains the new ARAP
+ password DES-encrypted using the old ARAP password as the key.
+
+2.6.3. MS-ARAP-Password-Change-Reason
+
+ Description
+
+ The MS-ARAP-Password-Change-Reason Attribute is used to indicate
+ reason for a server-initiated password change. It MAY be included
+ in Access-Challenge packets.
+
+ A summary of the MS-ARAP-Password-Change-Reason Attribute format is
+ given below. The fields are transmitted left to right.
+
+
+
+
+
+
+
+
+
+
+Zorn Informational [Page 29]
+
+RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor-Type | Vendor-Length | Why
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Why (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Vendor-Type
+ 21 for MS-ARAP-Password-Change-Reason
+
+ Vendor-Length
+ 6
+
+ Why
+ The Why field is 4 octets in length. The following values are
+ defined:
+ Just-Change-Password 1
+ Expired-Password 2
+ Admin-Requires-Password-Change 3
+ Password-Too-Short 4
+
+2.6.4. MS-ARAP-Challenge
+
+ Description
+
+ This attribute is only present in an Access-Request packet
+ containing a Framed-Protocol Attribute with the value 3 (ARAP).
+
+ A summary of the MS-ARAP-Challenge Attribute format is given below.
+ The fields are transmitted 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor-Type | Vendor-Length | Challenge
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Challenge (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Challenge (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Vendor-Type
+ 33 for MS-ARAP-Challenge
+
+ Vendor-Length
+ 10
+
+
+
+
+Zorn Informational [Page 30]
+
+RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
+
+
+ Value
+ The Challenge Field is 8 octets in length. It contains the
+ challenge (as two 4-octet quantities) sent by the NAS to the peer.
+
+2.7. Miscellaneous Attributes
+
+ This section describes attributes which do not fall into any
+ particular category, but are used in the identification and operation
+ of Microsoft remote access products.
+
+2.7.1. MS-RAS-Vendor
+
+ Description
+
+ The MS-RAS-Vendor Attribute is used to indicate the manufacturer
+ of the RADIUS client machine. It MAY be included in both Access-
+ Request and Accounting-Request packets.
+
+ A summary of the MS-RAS-Vendor Attribute format is given below. The
+ fields are transmitted 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor-Type | Vendor-Length | Vendor-ID
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Vendor-ID (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Vendor-Type
+ 9 for MS-RAS-Vendor
+
+ Vendor-Length
+ 6
+
+ Vendor-ID
+ The Vendor-ID field is 4 octets in length. The high-order octet
+ is 0 and the low-order 3 octets are the SMI Network Management
+ Private Enterprise Code of the Vendor in network byte order, as
+ defined in the Assigned Numbers RFC [13].
+
+2.7.2. MS-RAS-Version
+
+ Description
+
+ The MS-RAS-Version Attribute is used to indicate the version of
+ the RADIUS client software. This attribute SHOULD be included in
+ packets containing an MS-RAS-Vendor Attribute; it SHOULD NOT be
+
+
+
+Zorn Informational [Page 31]
+
+RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
+
+
+ sent in packets which do not contain an MS-RAS-Vendor Attribute.
+ It MAY be included in both Access-Request and Accounting-Request
+ packets.
+
+ A summary of the MS-RAS-Version Attribute format is given below. The
+ fields are transmitted 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor-Type | Vendor-Length | String...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Vendor-Type
+ 18 for MS-RAS-Version
+
+ Vendor-Length
+ > 3
+
+ String
+ The String field is one or more octets. The actual format of the
+ information is vendor specific, and a robust implementation SHOULD
+ support the field as undistinguished octets.
+
+2.7.3. MS-Filter
+
+ Description
+
+ The MS-Filter Attribute is used to transmit traffic filters. It
+ MAY be included in both Access-Accept and Accounting-Request
+ packets.
+
+ If multiple MS-Filter Attributes are contained within a packet,
+ they MUST be in order and they MUST be consecutive attributes in
+ the packet.
+
+ A summary of the MS-Filter Attribute format is given below. The
+ fields are transmitted 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor-Type | Vendor-Length | Filter...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Vendor-Type
+ 22 for MS-Filter Attribute
+
+
+
+
+Zorn Informational [Page 32]
+
+RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
+
+
+ Vendor-Length
+ > 3
+
+ Filter
+ The Filter field is one or more octets. It contains a sequence of
+ undifferentiated octets.
+
+ If multiple MS-Filter Attributes occur in a single Access-Accept
+ packet, the Filter field from each MUST be concatenated in the
+ order received to form the actual filter.
+
+2.7.4. MS-Acct-Auth-Type
+
+ Description
+
+ The MS-Acct-Auth-Type Attribute is used to represent the method
+ used to authenticate the dial-up user. It MAY be included in
+ Accounting-Request packets.
+
+ A summary of the MS-Acct-Auth-Type Attribute format is given below.
+ The fields are transmitted 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor-Type | Vendor-Length | Auth-Type
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Auth-Type (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Vendor-Type
+ 23 for MS-Acct-Auth-Type
+
+ Vendor-Length
+ 6
+
+ Auth-Type
+ The Auth-Type field is 4 octets in length. The following values
+ are defined for this field:
+
+ PAP 1
+ CHAP 2
+ MS-CHAP-1 3
+ MS-CHAP-2 4
+ EAP 5
+
+
+
+
+
+
+Zorn Informational [Page 33]
+
+RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
+
+
+2.7.5. MS-Acct-EAP-Type
+
+ Description
+
+ The MS-Acct-EAP-Type Attribute is used to represent the Extensible
+ Authentication Protocol (EAP) [15] type used to authenticate the
+ dial-up user. It MAY be included in Accounting-Request packets.
+
+ A summary of the MS-Acct-EAP-Type Attribute format is given below.
+ The fields are transmitted 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor-Type | Vendor-Length | EAP-Type
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ EAP-Type (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Vendor-Type
+ 24 for MS-Acct-EAP-Type
+
+ Vendor-Length
+ 6
+
+ Auth-Type
+ The EAP-Type field is 4 octets in length. The following values
+ are currently defined for this field:
+
+ MD5 4
+ OTP 5
+ Generic Token Card 6
+ TLS 13
+
+2.7.6. MS-Primary-DNS-Server
+
+ Description
+
+ The MS-Primary-DNS-Server Attribute is used to indicate the
+ address of the primary Domain Name Server (DNS) [16, 17] server to
+ be used by the PPP peer. It MAY be included in both Access-Accept
+ and Accounting-Request packets.
+
+ A summary of the MS-Primary-DNS-Server Attribute format is given
+ below. The fields are transmitted left to right.
+
+
+
+
+
+
+Zorn Informational [Page 34]
+
+RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor-Type | Vendor-Length | IP-Address
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ IP-Address (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Vendor-Type
+ 28 for MS-Primary-DNS-Server
+
+ Vendor-Length
+ 6
+
+ IP-Address
+ The IP-Address field is 4 octets in length. It contains the IP
+ address of the primary DNS server.
+
+2.7.7. MS-Secondary-DNS-Server
+
+ Description
+
+ The MS-Secondary-DNS-Server Attribute is used to indicate the
+ address of the secondary DNS server to be used by the PPP peer.
+ It MAY be included in both Access-Accept and Accounting-Request
+ packets.
+
+ A summary of the MS-Secondary-DNS-Server Attribute format is given
+ below. The fields are transmitted 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor-Type | Vendor-Length | IP-Address
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ IP-Address (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Vendor-Type
+ 29 for MS-Secondary-DNS-Server
+
+ Vendor-Length
+ 6
+
+ IP-Address
+ The IP-Address field is 4 octets in length. It contains the IP
+ address of the secondary DNS server.
+
+
+
+
+Zorn Informational [Page 35]
+
+RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
+
+
+2.7.8. MS-Primary-NBNS-Server
+
+ Description
+
+ The MS-Primary-NBNS-Server Attribute is used to indicate the
+ address of the primary NetBIOS Name Server (NBNS) [18] server to
+ be used by the PPP peer. It MAY be included in both Access-Accept
+ and Accounting-Request packets.
+
+ A summary of the MS-Primary-MBNS-Server Attribute format is given
+ below. The fields are transmitted 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor-Type | Vendor-Length | IP-Address
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ IP-Address (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Vendor-Type
+ 30 for MS-Primary-NBNS-Server
+
+ Vendor-Length
+ 6
+
+ IP-Address
+ The IP-Address field is 4 octets in length. It contains the IP
+ address of the primary NBNS server.
+
+2.7.9. MS-Secondary-NBNS-Server
+
+ Description
+
+ The MS-Secondary-NBNS-Server Attribute is used to indicate the
+ address of the secondary DNS server to be used by the PPP peer.
+ It MAY be included in both Access-Accept and Accounting-Request
+ packets.
+
+ A summary of the MS-Secondary-NBNS-Server Attribute format is given
+ below. The fields are transmitted left to right.
+
+
+
+
+
+
+
+
+
+
+Zorn Informational [Page 36]
+
+RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor-Type | Vendor-Length | IP-Address
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ IP-Address (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Vendor-Type
+ 31 for MS-Secondary-NBNS-Server
+
+ Vendor-Length
+ 6
+
+ IP-Address
+ The IP-Address field is 4 octets in length. It contains the IP
+ address of the secondary NBNS server.
+
+3. Table of Attributes
+
+ The following table provides a guide to which of the above attributes
+ may be found in which kinds of packets, and in what quantity.
+
+ Request Accept Reject Challenge Acct-Request # Attribute
+ 0-1 0 0 0 0 1 MS-CHAP-Response
+ 0 0 0-1 0 0 2 MS-CHAP-Error
+ 0-1 0 0 0 0 3 MS-CHAP-CPW-1
+ 0-1 0 0 0 0 4 MS-CHAP-CPW-2
+ 0+ 0 0 0 0 5 MS-CHAP-LM-Enc-PW
+ 0+ 0 0 0 0 6 MS-CHAP-NT-Enc-PW
+ 0 0-1 0 0 0 7 MS-MPPE-Encryption-
+ Policy
+ 0 0-1 0 0 0 8 MS-MPPE-Encryption-Type
+ 0-1 0 0 0 0-1 9 MS-RAS-Vendor
+ 0 0-1 0 0 0-1 10 MS-CHAP-Domain
+ 0-1 0 0 0-1 0 11 MS-CHAP-Challenge
+ 0 0-1 0 0 0 12 MS-CHAP-MPPE-Keys
+ 0 0-1 0 0 0 13 MS-BAP-Usage
+ 0 0-1 0 0 0 14 MS-Link-Utilization-
+ Threshold
+ 0 0-1 0 0 0 15 MS-Link-Drop-Time-Limit
+ 0 0-1 0 0 0 16 MS-MPPE-Send-Key
+ 0 0-1 0 0 0 17 MS-MPPE-Recv-Key
+ 0-1 0 0 0 0-1 18 MS-RAS-Version
+ 0-1 0 0 0 0 19 MS-Old-ARAP-Password
+ 0-1 0 0 0 0 20 MS-New-ARAP-Password
+ 0 0 0 0-1 0 21 MS-ARAP-PW-Change-
+ Reason
+
+
+
+Zorn Informational [Page 37]
+
+RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
+
+
+ 0 0+ 0 0 0+ 22 MS-Filter
+ 0 0 0 0 0-1 23 MS-Acct-Auth-Type
+ 0 0 0 0 0-1 24 MS-Acct-EAP-Type
+ 0-1 0 0 0 0 25 MS-CHAP2-Response
+ 0 0-1 0 0 0 26 MS-CHAP2-Success
+ 0-1 0 0 0 0 27 MS-CHAP2-CPW
+ 0 0-1 0 0 0-1 28 MS-Primary-DNS-Server
+ 0 0-1 0 0 0-1 29 MS-Secondary-DNS-Server
+ 0 0-1 0 0 0-1 30 MS-Primary-NBNS-Server
+ 0 0-1 0 0 0-1 31 MS-Secondary-NBNS-
+ Server
+ 0-1 0 0 0 0 33 MS-ARAP-Challenge
+
+The following table defines the meaning of the above table entries.
+
+0 This attribute MUST NOT be present in packet.
+0+ Zero or more instances of this attribute MAY be present in packet.
+0-1 Zero or one instance of this attribute MAY be present in packet.
+
+4. Security Considerations
+
+ MS-CHAP, like PPP CHAP, is susceptible to dictionary attacks. User
+ passwords should be chosen with care, and be of sufficient length to
+ deter easy guessing.
+
+ Although the scheme used to protect the Keys field of the MS-CHAP-
+ MPPE-Keys, MS-MPPE-Send-Key and MS-MPPE-Recv-Key Attributes is
+ believed to be relatively secure on the wire, RADIUS proxies will
+ decrypt and re-encrypt the field for forwarding. Therefore, these
+ attributes SHOULD NOT be used on networks where untrusted RADIUS
+ proxies reside.
+
+5. Acknowledgements
+
+ Thanks to Carl Rigney (cdr@livingston.com), Ashwin Palekar (ash-
+ winp@microsoft.com), Aydin Edguer (edguer@MorningStar.com), Narendra
+ Gidwani (nareng@microsoft.com), Steve Cobb (stevec@microsoft.com),
+ Pat Calhoun (pcalhoun@eng.sun.com), Dave Mitton
+ (dmitton@baynetworks.com), Paul Funk (paul@funk.com), Gurdeep Singh
+ Pall (gurdeep@microsoft.com), Stephen Bensley (sbens@microsoft.com),
+ and Don Rule (don-aldr@microsoft.com) for useful suggestions and
+ editorial feedback.
+
+
+
+
+
+
+
+
+
+Zorn Informational [Page 38]
+
+RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
+
+
+6. Editor's Address
+
+ Questions about this memo can 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
+
+7. References
+
+ [1] Simpson, W., "PPP Challenge Handshake Authentication
+ Protocol (CHAP)", RFC 1994, August 1996.
+
+ [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [3] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
+ Access Dial In User Service", RFC 2138, April 1997.
+
+ [4] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 2433,
+ October 1998.
+
+ [5] Simpson, W., "PPP Challenge Handshake Authentication Protocol
+ (CHAP)", RFC 1994, August 1996.
+
+ [6] Zorn, G. and G. Pall, "Microsoft Point-to-Point Encryption
+ (MPPE) Protocol", Work in Progress.
+
+ [7] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
+ 1661, July 1994.
+
+ [8] 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
+
+ [9] Pall, G., "Microsoft Point-to-Point Compression (MPPC)
+ Protocol", RFC 2118, March 1997.
+
+ [10] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC
+ 1962, June 1996.
+
+
+
+Zorn Informational [Page 39]
+
+RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
+
+
+ [11] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti,
+ "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
+
+ [12] Richards, C. and K. Smith, "The PPP Bandwidth Allocation
+ Protocol (BAP) The PPP Bandwidth Allocation Control Protocol
+ (BACP)", RFC 2125, March 1997.
+
+ [13] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
+ October 1994.
+
+ [14] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", Work in
+ Progress.
+
+ [15] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
+ Protocol (EAP)", RFC 2284, March 1998.
+
+ [16] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
+ 13, RFC 1034, USC/ISI, November 1987.
+
+ [17] Mockapetris, P., "Domain Names - Implementation and
+ Specification", STD 13, RFC 1035, November 1987.
+
+ [18] Auerbach, K., and A. Aggarwal, "Protocol Standard for a NetBIOS
+ Service on a TCP/UDP Transport", STD 19, RFCs 1001 and 1002,
+ March 1987.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zorn Informational [Page 40]
+
+RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
+
+
+10. 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zorn Informational [Page 41]
+
diff --git a/rfc/rfc2637.txt b/rfc/rfc2637.txt
new file mode 100644
index 0000000..56e9e0f
--- /dev/null
+++ b/rfc/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/rfc/rfc2716.txt b/rfc/rfc2716.txt
new file mode 100644
index 0000000..71b4a84
--- /dev/null
+++ b/rfc/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/rfc/rfc2759.txt b/rfc/rfc2759.txt
new file mode 100644
index 0000000..60371c4
--- /dev/null
+++ b/rfc/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/rfc/rfc2865.txt b/rfc/rfc2865.txt
new file mode 100644
index 0000000..10ec231
--- /dev/null
+++ b/rfc/rfc2865.txt
@@ -0,0 +1,4259 @@
+
+
+
+
+
+
+Network Working Group C. Rigney
+Request for Comments: 2865 S. Willens
+Obsoletes: 2138 Livingston
+Category: Standards Track A. Rubens
+ Merit
+ W. Simpson
+ Daydreamer
+ June 2000
+
+
+ Remote Authentication Dial In User Service (RADIUS)
+
+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 (2000). All Rights Reserved.
+
+IESG Note:
+
+ This protocol is widely implemented and used. Experience has shown
+ that it can suffer degraded performance and lost data when used in
+ large scale systems, in part because it does not include provisions
+ for congestion control. Readers of this document may find it
+ beneficial to track the progress of the IETF's AAA working group,
+ which may develop a successor protocol that better addresses the
+ scaling and congestion control issues.
+
+Abstract
+
+ This document describes a protocol for carrying authentication,
+ authorization, and configuration information between a Network Access
+ Server which desires to authenticate its links and a shared
+ Authentication Server.
+
+Implementation Note
+
+ This memo documents the RADIUS protocol. The early deployment of
+ RADIUS was done using UDP port number 1645, which conflicts with the
+ "datametrics" service. The officially assigned port number for
+ RADIUS is 1812.
+
+
+
+
+Rigney, et al. Standards Track [Page 1]
+
+RFC 2865 RADIUS June 2000
+
+
+Table of Contents
+
+ 1. Introduction .......................................... 3
+ 1.1 Specification of Requirements ................... 4
+ 1.2 Terminology ..................................... 5
+ 2. Operation ............................................. 5
+ 2.1 Challenge/Response .............................. 7
+ 2.2 Interoperation with PAP and CHAP ................ 8
+ 2.3 Proxy ........................................... 8
+ 2.4 Why UDP? ........................................ 11
+ 2.5 Retransmission Hints ............................ 12
+ 2.6 Keep-Alives Considered Harmful .................. 13
+ 3. Packet Format ......................................... 13
+ 4. Packet Types .......................................... 17
+ 4.1 Access-Request .................................. 17
+ 4.2 Access-Accept ................................... 18
+ 4.3 Access-Reject ................................... 20
+ 4.4 Access-Challenge ................................ 21
+ 5. Attributes ............................................ 22
+ 5.1 User-Name ....................................... 26
+ 5.2 User-Password ................................... 27
+ 5.3 CHAP-Password ................................... 28
+ 5.4 NAS-IP-Address .................................. 29
+ 5.5 NAS-Port ........................................ 30
+ 5.6 Service-Type .................................... 31
+ 5.7 Framed-Protocol ................................. 33
+ 5.8 Framed-IP-Address ............................... 34
+ 5.9 Framed-IP-Netmask ............................... 34
+ 5.10 Framed-Routing .................................. 35
+ 5.11 Filter-Id ....................................... 36
+ 5.12 Framed-MTU ...................................... 37
+ 5.13 Framed-Compression .............................. 37
+ 5.14 Login-IP-Host ................................... 38
+ 5.15 Login-Service ................................... 39
+ 5.16 Login-TCP-Port .................................. 40
+ 5.17 (unassigned) .................................... 41
+ 5.18 Reply-Message ................................... 41
+ 5.19 Callback-Number ................................. 42
+ 5.20 Callback-Id ..................................... 42
+ 5.21 (unassigned) .................................... 43
+ 5.22 Framed-Route .................................... 43
+ 5.23 Framed-IPX-Network .............................. 44
+ 5.24 State ........................................... 45
+ 5.25 Class ........................................... 46
+ 5.26 Vendor-Specific ................................. 47
+ 5.27 Session-Timeout ................................. 48
+ 5.28 Idle-Timeout .................................... 49
+ 5.29 Termination-Action .............................. 49
+
+
+
+Rigney, et al. Standards Track [Page 2]
+
+RFC 2865 RADIUS June 2000
+
+
+ 5.30 Called-Station-Id ............................... 50
+ 5.31 Calling-Station-Id .............................. 51
+ 5.32 NAS-Identifier .................................. 52
+ 5.33 Proxy-State ..................................... 53
+ 5.34 Login-LAT-Service ............................... 54
+ 5.35 Login-LAT-Node .................................. 55
+ 5.36 Login-LAT-Group ................................. 56
+ 5.37 Framed-AppleTalk-Link ........................... 57
+ 5.38 Framed-AppleTalk-Network ........................ 58
+ 5.39 Framed-AppleTalk-Zone ........................... 58
+ 5.40 CHAP-Challenge .................................. 59
+ 5.41 NAS-Port-Type ................................... 60
+ 5.42 Port-Limit ...................................... 61
+ 5.43 Login-LAT-Port .................................. 62
+ 5.44 Table of Attributes ............................. 63
+ 6. IANA Considerations ................................... 64
+ 6.1 Definition of Terms ............................. 64
+ 6.2 Recommended Registration Policies ............... 65
+ 7. Examples .............................................. 66
+ 7.1 User Telnet to Specified Host ................... 66
+ 7.2 Framed User Authenticating with CHAP ............ 67
+ 7.3 User with Challenge-Response card ............... 68
+ 8. Security Considerations ............................... 71
+ 9. Change Log ............................................ 71
+ 10. References ............................................ 73
+ 11. Acknowledgements ...................................... 74
+ 12. Chair's Address ....................................... 74
+ 13. Authors' Addresses .................................... 75
+ 14. Full Copyright Statement .............................. 76
+
+1. Introduction
+
+ This document obsoletes RFC 2138 [1]. A summary of the changes
+ between this document and RFC 2138 is available in the "Change Log"
+ appendix.
+
+ Managing dispersed serial line and modem pools for large numbers of
+ users can create the need for significant administrative support.
+ Since modem pools are by definition a link to the outside world, they
+ require careful attention to security, authorization and accounting.
+ This can be best achieved by managing a single "database" of users,
+ which allows for authentication (verifying user name and password) as
+ well as configuration information detailing the type of service to
+ deliver to the user (for example, SLIP, PPP, telnet, rlogin).
+
+
+
+
+
+
+
+Rigney, et al. Standards Track [Page 3]
+
+RFC 2865 RADIUS June 2000
+
+
+ Key features of RADIUS are:
+
+ Client/Server Model
+
+ A Network Access Server (NAS) operates as a client of RADIUS. The
+ client is responsible for passing user information to designated
+ RADIUS servers, and then acting on the response which is returned.
+
+ RADIUS servers are responsible for receiving user connection
+ requests, authenticating the user, and then returning all
+ configuration information necessary for the client to deliver
+ service to the user.
+
+ A RADIUS server can act as a proxy client to other RADIUS servers
+ or other kinds of authentication servers.
+
+ Network Security
+
+ Transactions between the client and RADIUS server are
+ authenticated through the use of a shared secret, which is never
+ sent over the network. In addition, any user passwords are sent
+ encrypted between the client and RADIUS server, to eliminate the
+ possibility that someone snooping on an unsecure network could
+ determine a user's password.
+
+ Flexible Authentication Mechanisms
+
+ The RADIUS server can support a variety of methods to authenticate
+ a user. When it is provided with the user name and original
+ password given by the user, it can support PPP PAP or CHAP, UNIX
+ login, and other authentication mechanisms.
+
+ Extensible Protocol
+
+ All transactions are comprised of variable length Attribute-
+ Length-Value 3-tuples. New attribute values can be added without
+ disturbing existing implementations of the protocol.
+
+1.1. Specification of Requirements
+
+ 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 BCP 14 [2]. These key
+ words mean the same thing whether capitalized or not.
+
+ An implementation is not compliant if it fails to satisfy one or more
+ of the must or must not requirements for the protocols it implements.
+ An implementation that satisfies all the must, must not, should and
+
+
+
+Rigney, et al. Standards Track [Page 4]
+
+RFC 2865 RADIUS June 2000
+
+
+ should not requirements for its protocols is said to be
+ "unconditionally compliant"; one that satisfies all the must and must
+ not requirements but not all the should or should not requirements
+ for its protocols is said to be "conditionally compliant".
+
+ A NAS that does not implement a given service MUST NOT implement the
+ RADIUS attributes for that service. For example, a NAS that is
+ unable to offer ARAP service MUST NOT implement the RADIUS attributes
+ for ARAP. A NAS MUST treat a RADIUS access-accept authorizing an
+ unavailable service as an access-reject instead.
+
+1.2. Terminology
+
+ This document frequently uses the following terms:
+
+ service The NAS provides a service to the dial-in user, such as PPP
+ or Telnet.
+
+ session Each service provided by the NAS to a dial-in user
+ constitutes a session, with the beginning of the session
+ defined as the point where service is first provided and
+ the end of the session defined as the point where service
+ is ended. A user may have multiple sessions in parallel or
+ series if the NAS supports that.
+
+ 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. Operation
+
+ When a client is configured to use RADIUS, any user of the client
+ presents authentication information to the client. This might be
+ with a customizable login prompt, where the user is expected to enter
+ their username and password. Alternatively, the user might use a
+ link framing protocol such as the Point-to-Point Protocol (PPP),
+ which has authentication packets which carry this information.
+
+ Once the client has obtained such information, it may choose to
+ authenticate using RADIUS. To do so, the client creates an "Access-
+ Request" containing such Attributes as the user's name, the user's
+ password, the ID of the client and the Port ID which the user is
+ accessing. When a password is present, it is hidden using a method
+ based on the RSA Message Digest Algorithm MD5 [3].
+
+
+
+
+Rigney, et al. Standards Track [Page 5]
+
+RFC 2865 RADIUS June 2000
+
+
+ The Access-Request is submitted to the RADIUS server via the network.
+ If no response is returned within a length of time, the request is
+ re-sent a number of times. The client can also forward requests to
+ an alternate server or servers in the event that the primary server
+ is down or unreachable. An alternate server can be used either after
+ a number of tries to the primary server fail, or in a round-robin
+ fashion. Retry and fallback algorithms are the topic of current
+ research and are not specified in detail in this document.
+
+ Once the RADIUS server receives the request, it validates the sending
+ client. A request from a client for which the RADIUS server does not
+ have a shared secret MUST be silently discarded. If the client is
+ valid, the RADIUS server consults a database of users to find the
+ user whose name matches the request. The user entry in the database
+ contains a list of requirements which must be met to allow access for
+ the user. This always includes verification of the password, but can
+ also specify the client(s) or port(s) to which the user is allowed
+ access.
+
+ The RADIUS server MAY make requests of other servers in order to
+ satisfy the request, in which case it acts as a client.
+
+ If any Proxy-State attributes were present in the Access-Request,
+ they MUST be copied unmodified and in order into the response packet.
+ Other Attributes can be placed before, after, or even between the
+ Proxy-State attributes.
+
+ If any condition is not met, the RADIUS server sends an "Access-
+ Reject" response indicating that this user request is invalid. If
+ desired, the server MAY include a text message in the Access-Reject
+ which MAY be displayed by the client to the user. No other
+ Attributes (except Proxy-State) are permitted in an Access-Reject.
+
+ If all conditions are met and the RADIUS server wishes to issue a
+ challenge to which the user must respond, the RADIUS server sends an
+ "Access-Challenge" response. It MAY include a text message to be
+ displayed by the client to the user prompting for a response to the
+ challenge, and MAY include a State attribute.
+
+ If the client receives an Access-Challenge and supports
+ challenge/response it MAY display the text message, if any, to the
+ user, and then prompt the user for a response. The client then re-
+ submits its original Access-Request with a new request ID, with the
+ User-Password Attribute replaced by the response (encrypted), and
+ including the State Attribute from the Access-Challenge, if any.
+ Only 0 or 1 instances of the State Attribute SHOULD be
+
+
+
+
+
+Rigney, et al. Standards Track [Page 6]
+
+RFC 2865 RADIUS June 2000
+
+
+ present in a request. The server can respond to this new Access-
+ Request with either an Access-Accept, an Access-Reject, or another
+ Access-Challenge.
+
+ If all conditions are met, the list of configuration values for the
+ user are placed into an "Access-Accept" response. These values
+ include the type of service (for example: SLIP, PPP, Login User) and
+ all necessary values to deliver the desired service. For SLIP and
+ PPP, this may include values such as IP address, subnet mask, MTU,
+ desired compression, and desired packet filter identifiers. For
+ character mode users, this may include values such as desired
+ protocol and host.
+
+2.1. Challenge/Response
+
+ In challenge/response authentication, the user is given an
+ unpredictable number and challenged to encrypt it and give back the
+ result. Authorized users are equipped with special devices such as
+ smart cards or software that facilitate calculation of the correct
+ response with ease. Unauthorized users, lacking the appropriate
+ device or software and lacking knowledge of the secret key necessary
+ to emulate such a device or software, can only guess at the response.
+
+ The Access-Challenge packet typically contains a Reply-Message
+ including a challenge to be displayed to the user, such as a numeric
+ value unlikely ever to be repeated. Typically this is obtained from
+ an external server that knows what type of authenticator is in the
+ possession of the authorized user and can therefore choose a random
+ or non-repeating pseudorandom number of an appropriate radix and
+ length.
+
+ The user then enters the challenge into his device (or software) and
+ it calculates a response, which the user enters into the client which
+ forwards it to the RADIUS server via a second Access-Request. If the
+ response matches the expected response the RADIUS server replies with
+ an Access-Accept, otherwise an Access-Reject.
+
+ Example: The NAS sends an Access-Request packet to the RADIUS Server
+ with NAS-Identifier, NAS-Port, User-Name, User-Password (which may
+ just be a fixed string like "challenge" or ignored). The server
+ sends back an Access-Challenge packet with State and a Reply-Message
+ along the lines of "Challenge 12345678, enter your response at the
+ prompt" which the NAS displays. The NAS prompts for the response and
+ sends a NEW Access-Request to the server (with a new ID) with NAS-
+ Identifier, NAS-Port, User-Name, User-Password (the response just
+ entered by the user, encrypted), and the same State Attribute that
+
+
+
+
+
+Rigney, et al. Standards Track [Page 7]
+
+RFC 2865 RADIUS June 2000
+
+
+ came with the Access-Challenge. The server then sends back either an
+ Access-Accept or Access-Reject based on whether the response matches
+ the required value, or it can even send another Access-Challenge.
+
+2.2. Interoperation with PAP and CHAP
+
+ For PAP, the NAS takes the PAP ID and password and sends them in an
+ Access-Request packet as the User-Name and User-Password. The NAS MAY
+ include the Attributes Service-Type = Framed-User and Framed-Protocol
+ = PPP as a hint to the RADIUS server that PPP service is expected.
+
+ For CHAP, the NAS generates a random challenge (preferably 16 octets)
+ and sends it to the user, who returns a CHAP response along with a
+ CHAP ID and CHAP username. The NAS then sends an Access-Request
+ packet to the RADIUS server with the CHAP username as the User-Name
+ and with the CHAP ID and CHAP response as the CHAP-Password
+ (Attribute 3). The random challenge can either be included in the
+ CHAP-Challenge attribute or, if it is 16 octets long, it can be
+ placed in the Request Authenticator field of the Access-Request
+ packet. The NAS MAY include the Attributes Service-Type = Framed-
+ User and Framed-Protocol = PPP as a hint to the RADIUS server that
+ PPP service is expected.
+
+ The RADIUS server looks up a password based on the User-Name,
+ encrypts the challenge using MD5 on the CHAP ID octet, that password,
+ and the CHAP challenge (from the CHAP-Challenge attribute if present,
+ otherwise from the Request Authenticator), and compares that result
+ to the CHAP-Password. If they match, the server sends back an
+ Access-Accept, otherwise it sends back an Access-Reject.
+
+ If the RADIUS server is unable to perform the requested
+ authentication it MUST return an Access-Reject. For example, CHAP
+ requires that the user's password be available in cleartext to the
+ server so that it can encrypt the CHAP challenge and compare that to
+ the CHAP response. If the password is not available in cleartext to
+ the RADIUS server then the server MUST send an Access-Reject to the
+ client.
+
+2.3. Proxy
+
+ With proxy RADIUS, one RADIUS server receives an authentication (or
+ accounting) request from a RADIUS client (such as a NAS), forwards
+ the request to a remote RADIUS server, receives the reply from the
+ remote server, and sends that reply to the client, possibly with
+ changes to reflect local administrative policy. A common use for
+ proxy RADIUS is roaming. Roaming permits two or more administrative
+ entities to allow each other's users to dial in to either entity's
+ network for service.
+
+
+
+Rigney, et al. Standards Track [Page 8]
+
+RFC 2865 RADIUS June 2000
+
+
+ The NAS sends its RADIUS access-request to the "forwarding server"
+ which forwards it to the "remote server". The remote server sends a
+ response (Access-Accept, Access-Reject, or Access-Challenge) back to
+ the forwarding server, which sends it back to the NAS. The User-Name
+ attribute MAY contain a Network Access Identifier [8] for RADIUS
+ Proxy operations. The choice of which server receives the forwarded
+ request SHOULD be based on the authentication "realm". The
+ authentication realm MAY be the realm part of a Network Access
+ Identifier (a "named realm"). Alternatively, the choice of which
+ server receives the forwarded request MAY be based on whatever other
+ criteria the forwarding server is configured to use, such as Called-
+ Station-Id (a "numbered realm").
+
+ A RADIUS server can function as both a forwarding server and a remote
+ server, serving as a forwarding server for some realms and a remote
+ server for other realms. One forwarding server can act as a
+ forwarder for any number of remote servers. A remote server can have
+ any number of servers forwarding to it and can provide authentication
+ for any number of realms. One forwarding server can forward to
+ another forwarding server to create a chain of proxies, although care
+ must be taken to avoid introducing loops.
+
+ The following scenario illustrates a proxy RADIUS communication
+ between a NAS and the forwarding and remote RADIUS servers:
+
+ 1. A NAS sends its access-request to the forwarding server.
+
+ 2. The forwarding server forwards the access-request to the remote
+ server.
+
+ 3. The remote server sends an access-accept, access-reject or
+ access-challenge back to the forwarding server. For this example,
+ an access-accept is sent.
+
+ 4. The forwarding server sends the access-accept to the NAS.
+
+ The forwarding server MUST treat any Proxy-State attributes already
+ in the packet as opaque data. Its operation MUST NOT depend on the
+ content of Proxy-State attributes added by previous servers.
+
+ If there are any Proxy-State attributes in the request received from
+ the client, the forwarding server MUST include those Proxy-State
+ attributes in its reply to the client. The forwarding server MAY
+ include the Proxy-State attributes in the access-request when it
+ forwards the request, or MAY omit them in the forwarded request. If
+ the forwarding server omits the Proxy-State attributes in the
+ forwarded access-request, it MUST attach them to the response before
+ sending it to the client.
+
+
+
+Rigney, et al. Standards Track [Page 9]
+
+RFC 2865 RADIUS June 2000
+
+
+ We now examine each step in more detail.
+
+ 1. A NAS sends its access-request to the forwarding server. The
+ forwarding server decrypts the User-Password, if present, using
+ the shared secret it knows for the NAS. If a CHAP-Password
+ attribute is present in the packet and no CHAP-Challenge attribute
+ is present, the forwarding server MUST leave the Request-
+ Authenticator untouched or copy it to a CHAP-Challenge attribute.
+
+ '' The forwarding server MAY add one Proxy-State attribute to the
+ packet. (It MUST NOT add more than one.) If it adds a Proxy-
+ State, the Proxy-State MUST appear after any other Proxy-States in
+ the packet. The forwarding server MUST NOT modify any other
+ Proxy-States that were in the packet (it may choose not to forward
+ them, but it MUST NOT change their contents). The forwarding
+ server MUST NOT change the order of any attributes of the same
+ type, including Proxy-State.
+
+ 2. The forwarding server encrypts the User-Password, if present,
+ using the secret it shares with the remote server, sets the
+ Identifier as needed, and forwards the access-request to the
+ remote server.
+
+ 3. The remote server (if the final destination) verifies the user
+ using User-Password, CHAP-Password, or such method as future
+ extensions may dictate, and returns an access-accept, access-
+ reject or access-challenge back to the forwarding server. For
+ this example, an access-accept is sent. The remote server MUST
+ copy all Proxy-State attributes (and only the Proxy-State
+ attributes) in order from the access-request to the response
+ packet, without modifying them.
+
+ 4. The forwarding server verifies the Response Authenticator using
+ the secret it shares with the remote server, and silently discards
+ the packet if it fails verification. If the packet passes
+ verification, the forwarding server removes the last Proxy-State
+ (if it attached one), signs the Response Authenticator using the
+ secret it shares with the NAS, restores the Identifier to match
+ the one in the original request by the NAS, and sends the access-
+ accept to the NAS.
+
+ A forwarding server MAY need to modify attributes to enforce local
+ policy. Such policy is outside the scope of this document, with the
+ following restrictions. A forwarding server MUST not modify existing
+ Proxy-State, State, or Class attributes present in the packet.
+
+
+
+
+
+
+Rigney, et al. Standards Track [Page 10]
+
+RFC 2865 RADIUS June 2000
+
+
+ Implementers of forwarding servers should consider carefully which
+ values it is willing to accept for Service-Type. Careful
+ consideration must be given to the effects of passing along Service-
+ Types of NAS-Prompt or Administrative in a proxied Access-Accept, and
+ implementers may wish to provide mechanisms to block those or other
+ service types, or other attributes. Such mechanisms are outside the
+ scope of this document.
+
+2.4. Why UDP?
+
+ A frequently asked question is why RADIUS uses UDP instead of TCP as
+ a transport protocol. UDP was chosen for strictly technical reasons.
+
+ There are a number of issues which must be understood. RADIUS is a
+ transaction based protocol which has several interesting
+ characteristics:
+
+ 1. If the request to a primary Authentication server fails, a
+ secondary server must be queried.
+
+ To meet this requirement, a copy of the request must be kept above
+ the transport layer to allow for alternate transmission. This
+ means that retransmission timers are still required.
+
+ 2. The timing requirements of this particular protocol are
+ significantly different than TCP provides.
+
+ At one extreme, RADIUS does not require a "responsive" detection
+ of lost data. The user is willing to wait several seconds for the
+ authentication to complete. The generally aggressive TCP
+ retransmission (based on average round trip time) is not required,
+ nor is the acknowledgement overhead of TCP.
+
+ At the other extreme, the user is not willing to wait several
+ minutes for authentication. Therefore the reliable delivery of
+ TCP data two minutes later is not useful. The faster use of an
+ alternate server allows the user to gain access before giving up.
+
+ 3. The stateless nature of this protocol simplifies the use of UDP.
+
+ Clients and servers come and go. Systems are rebooted, or are
+ power cycled independently. Generally this does not cause a
+ problem and with creative timeouts and detection of lost TCP
+ connections, code can be written to handle anomalous events. UDP
+ however completely eliminates any of this special handling. Each
+ client and server can open their UDP transport just once and leave
+ it open through all types of failure events on the network.
+
+
+
+
+Rigney, et al. Standards Track [Page 11]
+
+RFC 2865 RADIUS June 2000
+
+
+ 4. UDP simplifies the server implementation.
+
+ In the earliest implementations of RADIUS, the server was single
+ threaded. This means that a single request was received,
+ processed, and returned. This was found to be unmanageable in
+ environments where the back-end security mechanism took real time
+ (1 or more seconds). The server request queue would fill and in
+ environments where hundreds of people were being authenticated
+ every minute, the request turn-around time increased to longer
+ than users were willing to wait (this was especially severe when a
+ specific lookup in a database or over DNS took 30 or more
+ seconds). The obvious solution was to make the server multi-
+ threaded. Achieving this was simple with UDP. Separate processes
+ were spawned to serve each request and these processes could
+ respond directly to the client NAS with a simple UDP packet to the
+ original transport of the client.
+
+ It's not all a panacea. As noted, using UDP requires one thing which
+ is built into TCP: with UDP we must artificially manage
+ retransmission timers to the same server, although they don't require
+ the same attention to timing provided by TCP. This one penalty is a
+ small price to pay for the advantages of UDP in this protocol.
+
+ Without TCP we would still probably be using tin cans connected by
+ string. But for this particular protocol, UDP is a better choice.
+
+2.5. Retransmission Hints
+
+ If the RADIUS server and alternate RADIUS server share the same
+ shared secret, it is OK to retransmit the packet to the alternate
+ RADIUS server with the same ID and Request Authenticator, because the
+ content of the attributes haven't changed. If you want to use a new
+ Request Authenticator when sending to the alternate server, you may.
+
+ If you change the contents of the User-Password attribute (or any
+ other attribute), you need a new Request Authenticator and therefore
+ a new ID.
+
+ If the NAS is retransmitting a RADIUS request to the same server as
+ before, and the attributes haven't changed, you MUST use the same
+ Request Authenticator, ID, and source port. If any attributes have
+ changed, you MUST use a new Request Authenticator and ID.
+
+ A NAS MAY use the same ID across all servers, or MAY keep track of
+ IDs separately for each server, it is up to the implementer. If a
+ NAS needs more than 256 IDs for outstanding requests, it MAY use
+
+
+
+
+
+Rigney, et al. Standards Track [Page 12]
+
+RFC 2865 RADIUS June 2000
+
+
+ additional source ports to send requests from, and keep track of IDs
+ for each source port. This allows up to 16 million or so outstanding
+ requests at one time to a single server.
+
+2.6. Keep-Alives Considered Harmful
+
+ Some implementers have adopted the practice of sending test RADIUS
+ requests to see if a server is alive. This practice is strongly
+ discouraged, since it adds to load and harms scalability without
+ providing any additional useful information. Since a RADIUS request
+ is contained in a single datagram, in the time it would take you to
+ send a ping you could just send the RADIUS request, and getting a
+ reply tells you that the RADIUS server is up. If you do not have a
+ RADIUS request to send, it does not matter if the server is up or
+ not, because you are not using it.
+
+ If you want to monitor your RADIUS server, use SNMP. That's what
+ SNMP is for.
+
+3. Packet Format
+
+ Exactly one RADIUS packet is encapsulated in the UDP Data field [4],
+ where the UDP Destination Port field indicates 1812 (decimal).
+
+ When a reply is generated, the source and destination ports are
+ reversed.
+
+ This memo documents the RADIUS protocol. The early deployment of
+ RADIUS was done using UDP port number 1645, which conflicts with the
+ "datametrics" service. The officially assigned port number for
+ RADIUS is 1812.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et al. Standards Track [Page 13]
+
+RFC 2865 RADIUS June 2000
+
+
+ A summary of the RADIUS data 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ | Authenticator |
+ | |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Attributes ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Code
+
+ The Code field is one octet, and identifies the type of RADIUS
+ packet. When a packet is received with an invalid Code field, it
+ is silently discarded.
+
+ RADIUS Codes (decimal) are assigned as follows:
+
+ 1 Access-Request
+ 2 Access-Accept
+ 3 Access-Reject
+ 4 Accounting-Request
+ 5 Accounting-Response
+ 11 Access-Challenge
+ 12 Status-Server (experimental)
+ 13 Status-Client (experimental)
+ 255 Reserved
+
+ Codes 4 and 5 are covered in the RADIUS Accounting document [5].
+ Codes 12 and 13 are reserved for possible use, but are not further
+ mentioned here.
+
+ Identifier
+
+ The Identifier field is one octet, and aids in matching requests
+ and replies. The RADIUS server can detect a duplicate request if
+ it has the same client source IP address and source UDP port and
+ Identifier within a short span of time.
+
+
+
+
+
+
+
+Rigney, et al. Standards Track [Page 14]
+
+RFC 2865 RADIUS June 2000
+
+
+ Length
+
+ The Length field is two octets. It indicates the length of the
+ packet including the Code, Identifier, Length, Authenticator and
+ Attribute fields. Octets outside the range of the Length field
+ MUST be treated as padding and ignored on reception. If the
+ packet is shorter than the Length field indicates, it MUST be
+ silently discarded. The minimum length is 20 and maximum length
+ is 4096.
+
+ Authenticator
+
+ The Authenticator field is sixteen (16) octets. The most
+ significant octet is transmitted first. This value is used to
+ authenticate the reply from the RADIUS server, and is used in the
+ password hiding algorithm.
+
+ Request Authenticator
+
+ In Access-Request Packets, the Authenticator value is a 16
+ octet random number, called the Request Authenticator. The
+ value SHOULD be unpredictable and unique over the lifetime of a
+ secret (the password shared between the client and the RADIUS
+ server), since repetition of a request 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 Request Authenticator field
+ SHOULD exhibit global and temporal uniqueness.
+
+ The Request Authenticator value in an Access-Request packet
+ SHOULD also be unpredictable, lest an attacker trick a server
+ into responding to a predicted future request, and then use the
+ response to masquerade as that server to a future Access-
+ Request.
+
+ Although protocols such as RADIUS are incapable of protecting
+ against theft of an authenticated session via realtime active
+ wiretapping attacks, generation of unique unpredictable
+ requests can protect against a wide range of active attacks
+ against authentication.
+
+ The NAS and RADIUS server share a secret. That shared secret
+ followed by the Request Authenticator is put through a one-way
+ MD5 hash to create a 16 octet digest value which is xored with
+ the password entered by the user, and the xored result placed
+
+
+
+
+
+Rigney, et al. Standards Track [Page 15]
+
+RFC 2865 RADIUS June 2000
+
+
+ in the User-Password attribute in the Access-Request packet.
+ See the entry for User-Password in the section on Attributes
+ for a more detailed description.
+
+ Response Authenticator
+
+ The value of the Authenticator field in Access-Accept, Access-
+ Reject, and Access-Challenge packets is called the Response
+ Authenticator, and contains a one-way MD5 hash calculated over
+ a stream of octets consisting of: the RADIUS packet, beginning
+ with the Code field, including the Identifier, the Length, the
+ Request Authenticator field from the Access-Request packet, and
+ the response Attributes, followed by the shared secret. That
+ is, ResponseAuth =
+ MD5(Code+ID+Length+RequestAuth+Attributes+Secret) where +
+ denotes concatenation.
+
+ Administrative Note
+
+ The secret (password shared between the client and the RADIUS
+ server) SHOULD be at least as large and unguessable as a well-
+ chosen password. It is preferred that the secret be at least 16
+ octets. This is to ensure a sufficiently large range for the
+ secret to provide protection against exhaustive search attacks.
+ The secret MUST NOT be empty (length 0) since this would allow
+ packets to be trivially forged.
+
+ A RADIUS server MUST use the source IP address of the RADIUS UDP
+ packet to decide which shared secret to use, so that RADIUS
+ requests can be proxied.
+
+ When using a forwarding proxy, the proxy must be able to alter the
+ packet as it passes through in each direction - when the proxy
+ forwards the request, the proxy MAY add a Proxy-State Attribute,
+ and when the proxy forwards a response, it MUST remove its Proxy-
+ State Attribute if it added one. Proxy-State is always added or
+ removed after any other Proxy-States, but no other assumptions
+ regarding its location within the list of attributes can be made.
+ Since Access-Accept and Access-Reject replies are authenticated on
+ the entire packet contents, the stripping of the Proxy-State
+ attribute invalidates the signature in the packet - so the proxy
+ has to re-sign it.
+
+ Further details of RADIUS proxy implementation are outside the
+ scope of this document.
+
+
+
+
+
+
+Rigney, et al. Standards Track [Page 16]
+
+RFC 2865 RADIUS June 2000
+
+
+4. Packet Types
+
+ The RADIUS Packet type is determined by the Code field in the first
+ octet of the Packet.
+
+4.1. Access-Request
+
+ Description
+
+ Access-Request packets are sent to a RADIUS server, and convey
+ information used to determine whether a user is allowed access to
+ a specific NAS, and any special services requested for that user.
+ An implementation wishing to authenticate a user MUST transmit a
+ RADIUS packet with the Code field set to 1 (Access-Request).
+
+ Upon receipt of an Access-Request from a valid client, an
+ appropriate reply MUST be transmitted.
+
+ An Access-Request SHOULD contain a User-Name attribute. It MUST
+ contain either a NAS-IP-Address attribute or a NAS-Identifier
+ attribute (or both).
+
+ An Access-Request MUST contain either a User-Password or a CHAP-
+ Password or a State. An Access-Request MUST NOT contain both a
+ User-Password and a CHAP-Password. If future extensions allow
+ other kinds of authentication information to be conveyed, the
+ attribute for that can be used in an Access-Request instead of
+ User-Password or CHAP-Password.
+
+ An Access-Request SHOULD contain a NAS-Port or NAS-Port-Type
+ attribute or both unless the type of access being requested does
+ not involve a port or the NAS does not distinguish among its
+ ports.
+
+ An Access-Request MAY contain additional attributes as a hint to
+ the server, but the server is not required to honor the hint.
+
+ When a User-Password is present, it is hidden using a method based
+ on the RSA Message Digest Algorithm MD5 [3].
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et al. Standards Track [Page 17]
+
+RFC 2865 RADIUS June 2000
+
+
+ A summary of the Access-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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ | Request Authenticator |
+ | |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Attributes ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Code
+
+ 1 for Access-Request.
+
+ Identifier
+
+ The Identifier field MUST be changed whenever the content of the
+ Attributes field changes, and whenever a valid reply has been
+ received for a previous request. For retransmissions, the
+ Identifier MUST remain unchanged.
+
+ Request Authenticator
+
+ The Request Authenticator value MUST be changed each time a new
+ Identifier is used.
+
+ Attributes
+
+ The Attribute field is variable in length, and contains the list
+ of Attributes that are required for the type of service, as well
+ as any desired optional Attributes.
+
+4.2. Access-Accept
+
+ Description
+
+ Access-Accept packets are sent by the RADIUS server, and provide
+ specific configuration information necessary to begin delivery of
+ service to the user. If all Attribute values received in an
+ Access-Request are acceptable then the RADIUS implementation MUST
+ transmit a packet with the Code field set to 2 (Access-Accept).
+
+
+
+
+Rigney, et al. Standards Track [Page 18]
+
+RFC 2865 RADIUS June 2000
+
+
+ On reception of an Access-Accept, the Identifier field is matched
+ with a pending Access-Request. The Response Authenticator field
+ MUST contain the correct response for the pending Access-Request.
+ Invalid packets are silently discarded.
+
+ A summary of the Access-Accept 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ | Response Authenticator |
+ | |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Attributes ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Code
+
+ 2 for Access-Accept.
+
+ Identifier
+
+ The Identifier field is a copy of the Identifier field of the
+ Access-Request which caused this Access-Accept.
+
+ Response Authenticator
+
+ The Response Authenticator value is calculated from the Access-
+ Request value, as described earlier.
+
+ Attributes
+
+ The Attribute field is variable in length, and contains a list of
+ zero or more Attributes.
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et al. Standards Track [Page 19]
+
+RFC 2865 RADIUS June 2000
+
+
+4.3. Access-Reject
+
+ Description
+
+ If any value of the received Attributes is not acceptable, then
+ the RADIUS server MUST transmit a packet with the Code field set
+ to 3 (Access-Reject). It MAY include one or more Reply-Message
+ Attributes with a text message which the NAS MAY display to the
+ user.
+
+ A summary of the Access-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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ | Response Authenticator |
+ | |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Attributes ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Code
+
+ 3 for Access-Reject.
+
+ Identifier
+
+ The Identifier field is a copy of the Identifier field of the
+ Access-Request which caused this Access-Reject.
+
+ Response Authenticator
+
+ The Response Authenticator value is calculated from the Access-
+ Request value, as described earlier.
+
+ Attributes
+
+ The Attribute field is variable in length, and contains a list of
+ zero or more Attributes.
+
+
+
+
+
+
+
+Rigney, et al. Standards Track [Page 20]
+
+RFC 2865 RADIUS June 2000
+
+
+4.4. Access-Challenge
+
+ Description
+
+ If the RADIUS server desires to send the user a challenge
+ requiring a response, then the RADIUS server MUST respond to the
+ Access-Request by transmitting a packet with the Code field set to
+ 11 (Access-Challenge).
+
+ The Attributes field MAY have one or more Reply-Message
+ Attributes, and MAY have a single State Attribute, or none.
+ Vendor-Specific, Idle-Timeout, Session-Timeout and Proxy-State
+ attributes MAY also be included. No other Attributes defined in
+ this document are permitted in an Access-Challenge.
+
+ On receipt of an Access-Challenge, the Identifier field is matched
+ with a pending Access-Request. Additionally, the Response
+ Authenticator field MUST contain the correct response for the
+ pending Access-Request. Invalid packets are silently discarded.
+
+ If the NAS does not support challenge/response, it MUST treat an
+ Access-Challenge as though it had received an Access-Reject
+ instead.
+
+ If the NAS supports challenge/response, receipt of a valid
+ Access-Challenge indicates that a new Access-Request SHOULD be
+ sent. The NAS MAY display the text message, if any, to the user,
+ and then prompt the user for a response. It then sends its
+ original Access-Request with a new request ID and Request
+ Authenticator, with the User-Password Attribute replaced by the
+ user's response (encrypted), and including the State Attribute
+ from the Access-Challenge, if any. Only 0 or 1 instances of the
+ State Attribute can be present in an Access-Request.
+
+ A NAS which supports PAP MAY forward the Reply-Message to the
+ dialing client and accept a PAP response which it can use as
+ though the user had entered the response. If the NAS cannot do
+ so, it MUST treat the Access-Challenge as though it had received
+ an Access-Reject instead.
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et al. Standards Track [Page 21]
+
+RFC 2865 RADIUS June 2000
+
+
+ A summary of the Access-Challenge 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ | Response Authenticator |
+ | |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Attributes ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Code
+
+ 11 for Access-Challenge.
+
+ Identifier
+
+ The Identifier field is a copy of the Identifier field of the
+ Access-Request which caused this Access-Challenge.
+
+ Response Authenticator
+
+ The Response Authenticator value is calculated from the Access-
+ Request value, as described earlier.
+
+ Attributes
+
+ The Attributes field is variable in length, and contains a list of
+ zero or more Attributes.
+
+5. Attributes
+
+ RADIUS Attributes carry the specific authentication, authorization,
+ information and configuration details for the request and reply.
+
+ The end of the list of Attributes is indicated by the Length of the
+ RADIUS packet.
+
+ Some Attributes MAY be included more than once. The effect of this
+ is Attribute specific, and is specified in each Attribute
+ description. A summary table is provided at the end of the
+ "Attributes" section.
+
+
+
+
+Rigney, et al. Standards Track [Page 22]
+
+RFC 2865 RADIUS June 2000
+
+
+ If multiple Attributes with the same Type are present, the order of
+ Attributes with the same Type MUST be preserved by any proxies. The
+ order of Attributes of different Types is not required to be
+ preserved. A RADIUS server or client MUST NOT have any dependencies
+ on the order of attributes of different types. A RADIUS server or
+ client MUST NOT require attributes of the same type to be contiguous.
+
+ Where an Attribute's description limits which kinds of packet it can
+ be contained in, this applies only to the packet types defined in
+ this document, namely Access-Request, Access-Accept, Access-Reject
+ and Access-Challenge (Codes 1, 2, 3, and 11). Other documents
+ defining other packet types may also use Attributes described here.
+ To determine which Attributes are allowed in Accounting-Request and
+ Accounting-Response packets (Codes 4 and 5) refer to the RADIUS
+ Accounting document [5].
+
+ Likewise where packet types defined here state that only certain
+ Attributes are permissible in them, future memos defining new
+ Attributes should indicate which packet types the new Attributes may
+ be present in.
+
+ A summary of the Attribute 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ | Type | Length | Value ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Type
+
+ The Type field is one octet. Up-to-date values of the RADIUS Type
+ field are specified in the most recent "Assigned Numbers" RFC [6].
+ Values 192-223 are reserved for experimental use, values 224-240
+ are reserved for implementation-specific use, and values 241-255
+ are reserved and should not be used.
+
+ A RADIUS server MAY ignore Attributes with an unknown Type.
+
+ A RADIUS client MAY ignore Attributes with an unknown Type.
+
+
+
+
+
+
+
+
+
+
+Rigney, et al. Standards Track [Page 23]
+
+RFC 2865 RADIUS June 2000
+
+
+ This specification concerns the following values:
+
+ 1 User-Name
+ 2 User-Password
+ 3 CHAP-Password
+ 4 NAS-IP-Address
+ 5 NAS-Port
+ 6 Service-Type
+ 7 Framed-Protocol
+ 8 Framed-IP-Address
+ 9 Framed-IP-Netmask
+ 10 Framed-Routing
+ 11 Filter-Id
+ 12 Framed-MTU
+ 13 Framed-Compression
+ 14 Login-IP-Host
+ 15 Login-Service
+ 16 Login-TCP-Port
+ 17 (unassigned)
+ 18 Reply-Message
+ 19 Callback-Number
+ 20 Callback-Id
+ 21 (unassigned)
+ 22 Framed-Route
+ 23 Framed-IPX-Network
+ 24 State
+ 25 Class
+ 26 Vendor-Specific
+ 27 Session-Timeout
+ 28 Idle-Timeout
+ 29 Termination-Action
+ 30 Called-Station-Id
+ 31 Calling-Station-Id
+ 32 NAS-Identifier
+ 33 Proxy-State
+ 34 Login-LAT-Service
+ 35 Login-LAT-Node
+ 36 Login-LAT-Group
+ 37 Framed-AppleTalk-Link
+ 38 Framed-AppleTalk-Network
+ 39 Framed-AppleTalk-Zone
+ 40-59 (reserved for accounting)
+ 60 CHAP-Challenge
+ 61 NAS-Port-Type
+ 62 Port-Limit
+ 63 Login-LAT-Port
+
+
+
+
+
+Rigney, et al. Standards Track [Page 24]
+
+RFC 2865 RADIUS June 2000
+
+
+ Length
+
+ The Length field is one octet, and indicates the length of this
+ Attribute including the Type, Length and Value fields. If an
+ Attribute is received in an Access-Request but with an invalid
+ Length, an Access-Reject SHOULD be transmitted. If an Attribute
+ is received in an Access-Accept, Access-Reject or Access-Challenge
+ packet with an invalid length, the packet MUST either be treated
+ as an Access-Reject or else silently discarded.
+
+ Value
+
+ The Value field is zero or more octets and contains information
+ specific to the Attribute. The format and length of the Value
+ field is determined by the Type and Length fields.
+
+ Note that none of the types in RADIUS terminate with a NUL (hex
+ 00). In particular, types "text" and "string" in RADIUS do not
+ terminate with a NUL (hex 00). The Attribute has a length field
+ and does not use a terminator. Text contains UTF-8 encoded 10646
+ [7] characters and String contains 8-bit binary data. Servers and
+ servers and clients MUST be able to deal with embedded nulls.
+ RADIUS implementers using C are cautioned not to use strcpy() when
+ handling strings.
+
+ The format of the value field is one of five data types. Note
+ that type "text" is a subset of type "string".
+
+ text 1-253 octets containing UTF-8 encoded 10646 [7]
+ characters. Text of length zero (0) MUST NOT be sent;
+ omit the entire attribute instead.
+
+ string 1-253 octets containing binary data (values 0 through
+ 255 decimal, inclusive). Strings of length zero (0)
+ MUST NOT be sent; omit the entire attribute instead.
+
+ address 32 bit value, most significant octet first.
+
+ integer 32 bit unsigned value, most significant octet first.
+
+ time 32 bit unsigned value, most significant octet first --
+ seconds since 00:00:00 UTC, January 1, 1970. The
+ standard Attributes do not use this data type but it is
+ presented here for possible use in future attributes.
+
+
+
+
+
+
+
+Rigney, et al. Standards Track [Page 25]
+
+RFC 2865 RADIUS June 2000
+
+
+5.1. User-Name
+
+ Description
+
+ This Attribute indicates the name of the user to be authenticated.
+ It MUST be sent in Access-Request packets if available.
+
+ It MAY be sent in an Access-Accept packet, in which case the
+ client SHOULD use the name returned in the Access-Accept packet in
+ all Accounting-Request packets for this session. If the Access-
+ Accept includes Service-Type = Rlogin and the User-Name attribute,
+ a NAS MAY use the returned User-Name when performing the Rlogin
+ function.
+
+ A summary of the User-Name Attribute 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ | Type | Length | String ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Type
+
+ 1 for User-Name.
+
+ Length
+
+ >= 3
+
+ String
+
+ The String field is one or more octets. The NAS may limit the
+ maximum length of the User-Name but the ability to handle at least
+ 63 octets is recommended.
+
+ The format of the username MAY be one of several forms:
+
+ text Consisting only of UTF-8 encoded 10646 [7] characters.
+
+ network access identifier
+ A Network Access Identifier as described in RFC 2486
+ [8].
+
+ distinguished name
+ A name in ASN.1 form used in Public Key authentication
+ systems.
+
+
+
+Rigney, et al. Standards Track [Page 26]
+
+RFC 2865 RADIUS June 2000
+
+
+5.2. User-Password
+
+ Description
+
+ This Attribute indicates the password of the user to be
+ authenticated, or the user's input following an Access-Challenge.
+ It is only used in Access-Request packets.
+
+ On transmission, the password is hidden. The password is first
+ padded at the end with nulls to a multiple of 16 octets. A one-
+ way MD5 hash is calculated over a stream of octets consisting of
+ the shared secret followed by the Request Authenticator. This
+ value is XORed with the first 16 octet segment of the password and
+ placed in the first 16 octets of the String field of the User-
+ Password Attribute.
+
+ If the password is longer than 16 characters, a second one-way MD5
+ hash is calculated over a stream of octets consisting of the
+ shared secret followed by the result of the first xor. That hash
+ is XORed with the second 16 octet segment of the password and
+ placed in the second 16 octets of the String field of the User-
+ Password Attribute.
+
+ If necessary, this operation is repeated, with each xor result
+ being used along with the shared secret to generate the next hash
+ to xor the next segment of the password, to no more than 128
+ characters.
+
+ The method is taken from the book "Network Security" by Kaufman,
+ Perlman and Speciner [9] pages 109-110. A more precise
+ explanation of the method follows:
+
+ Call the shared secret S and the pseudo-random 128-bit Request
+ Authenticator RA. Break the password into 16-octet chunks p1, p2,
+ etc. with the last one padded at the end with nulls to a 16-octet
+ boundary. Call the ciphertext blocks c(1), c(2), etc. We'll need
+ intermediate values b1, b2, etc.
+
+ b1 = MD5(S + RA) c(1) = p1 xor b1
+ b2 = MD5(S + c(1)) c(2) = p2 xor b2
+ . .
+ . .
+ . .
+ bi = MD5(S + c(i-1)) c(i) = pi xor bi
+
+ The String will contain c(1)+c(2)+...+c(i) where + denotes
+ concatenation.
+
+
+
+
+Rigney, et al. Standards Track [Page 27]
+
+RFC 2865 RADIUS June 2000
+
+
+ On receipt, the process is reversed to yield the original
+ password.
+
+ A summary of the User-Password Attribute 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ | Type | Length | String ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Type
+
+ 2 for User-Password.
+
+ Length
+
+ At least 18 and no larger than 130.
+
+ String
+
+ The String field is between 16 and 128 octets long, inclusive.
+
+5.3. CHAP-Password
+
+ Description
+
+ This Attribute indicates the response value provided by a PPP
+ Challenge-Handshake Authentication Protocol (CHAP) user in
+ response to the challenge. It is only used in Access-Request
+ packets.
+
+ The CHAP challenge value is found in the CHAP-Challenge Attribute
+ (60) if present in the packet, otherwise in the Request
+ Authenticator field.
+
+ A summary of the CHAP-Password Attribute 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 4 5 6 7 8 9
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ | Type | Length | CHAP Ident | String ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+
+
+
+
+
+Rigney, et al. Standards Track [Page 28]
+
+RFC 2865 RADIUS June 2000
+
+
+ Type
+
+ 3 for CHAP-Password.
+
+ Length
+
+ 19
+
+ CHAP Ident
+
+ This field is one octet, and contains the CHAP Identifier from the
+ user's CHAP Response.
+
+ String
+
+ The String field is 16 octets, and contains the CHAP Response from
+ the user.
+
+5.4. NAS-IP-Address
+
+ Description
+
+ This Attribute indicates the identifying IP Address of the NAS
+ which is requesting authentication of the user, and SHOULD be
+ unique to the NAS within the scope of the RADIUS server. NAS-IP-
+ Address is only used in Access-Request packets. Either NAS-IP-
+ Address or NAS-Identifier MUST be present in an Access-Request
+ packet.
+
+ Note that NAS-IP-Address MUST NOT be used to select the shared
+ secret used to authenticate the request. The source IP address of
+ the Access-Request packet MUST be used to select the shared
+ secret.
+
+ A summary of the NAS-IP-Address Attribute 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 | Address
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Address (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 4 for NAS-IP-Address.
+
+
+
+Rigney, et al. Standards Track [Page 29]
+
+RFC 2865 RADIUS June 2000
+
+
+ Length
+
+ 6
+
+ Address
+
+ The Address field is four octets.
+
+5.5. NAS-Port
+
+ Description
+
+ This Attribute indicates the physical port number of the NAS which
+ is authenticating the user. It is only used in Access-Request
+ packets. Note that this is using "port" in its sense of a
+ physical connection on the NAS, not in the sense of a TCP or UDP
+ port number. Either NAS-Port or NAS-Port-Type (61) or both SHOULD
+ be present in an Access-Request packet, if the NAS differentiates
+ among its ports.
+
+ A summary of the NAS-Port Attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 5 for NAS-Port.
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets.
+
+
+
+
+
+
+
+
+
+Rigney, et al. Standards Track [Page 30]
+
+RFC 2865 RADIUS June 2000
+
+
+5.6. Service-Type
+
+ Description
+
+ This Attribute indicates the type of service the user has
+ requested, or the type of service to be provided. It MAY be used
+ in both Access-Request and Access-Accept packets. A NAS is not
+ required to implement all of these service types, and MUST treat
+ unknown or unsupported Service-Types as though an Access-Reject
+ had been received instead.
+
+ A summary of the Service-Type Attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 6 for Service-Type.
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets.
+
+ 1 Login
+ 2 Framed
+ 3 Callback Login
+ 4 Callback Framed
+ 5 Outbound
+ 6 Administrative
+ 7 NAS Prompt
+ 8 Authenticate Only
+ 9 Callback NAS Prompt
+ 10 Call Check
+ 11 Callback Administrative
+
+
+
+
+
+
+Rigney, et al. Standards Track [Page 31]
+
+RFC 2865 RADIUS June 2000
+
+
+ The service types are defined as follows when used in an Access-
+ Accept. When used in an Access-Request, they MAY be considered to
+ be a hint to the RADIUS server that the NAS has reason to believe
+ the user would prefer the kind of service indicated, but the
+ server is not required to honor the hint.
+
+ Login The user should be connected to a host.
+
+ Framed A Framed Protocol should be started for the
+ User, such as PPP or SLIP.
+
+ Callback Login The user should be disconnected and called
+ back, then connected to a host.
+
+ Callback Framed The user should be disconnected and called
+ back, then a Framed Protocol should be started
+ for the User, such as PPP or SLIP.
+
+ Outbound The user should be granted access to outgoing
+ devices.
+
+ Administrative The user should be granted access to the
+ administrative interface to the NAS from which
+ privileged commands can be executed.
+
+ NAS Prompt The user should be provided a command prompt
+ on the NAS from which non-privileged commands
+ can be executed.
+
+ Authenticate Only Only Authentication is requested, and no
+ authorization information needs to be returned
+ in the Access-Accept (typically used by proxy
+ servers rather than the NAS itself).
+
+ Callback NAS Prompt The user should be disconnected and called
+ back, then provided a command prompt on the
+ NAS from which non-privileged commands can be
+ executed.
+
+ Call Check Used by the NAS in an Access-Request packet to
+ indicate that a call is being received and
+ that the RADIUS server should send back an
+ Access-Accept to answer the call, or an
+ Access-Reject to not accept the call,
+ typically based on the Called-Station-Id or
+ Calling-Station-Id attributes. It is
+
+
+
+
+
+Rigney, et al. Standards Track [Page 32]
+
+RFC 2865 RADIUS June 2000
+
+
+ recommended that such Access-Requests use the
+ value of Calling-Station-Id as the value of
+ the User-Name.
+
+ Callback Administrative
+ The user should be disconnected and called
+ back, then granted access to the
+ administrative interface to the NAS from which
+ privileged commands can be executed.
+
+5.7. Framed-Protocol
+
+ Description
+
+ This Attribute indicates the framing to be used for framed access.
+ It MAY be used in both Access-Request and Access-Accept packets.
+
+ A summary of the Framed-Protocol Attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 7 for Framed-Protocol.
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets.
+
+ 1 PPP
+ 2 SLIP
+ 3 AppleTalk Remote Access Protocol (ARAP)
+ 4 Gandalf proprietary SingleLink/MultiLink protocol
+ 5 Xylogics proprietary IPX/SLIP
+ 6 X.75 Synchronous
+
+
+
+
+
+Rigney, et al. Standards Track [Page 33]
+
+RFC 2865 RADIUS June 2000
+
+
+5.8. Framed-IP-Address
+
+ Description
+
+ This Attribute indicates the address to be configured for the
+ user. It MAY be used in Access-Accept packets. It MAY be used in
+ an Access-Request packet as a hint by the NAS to the server that
+ it would prefer that address, but the server is not required to
+ honor the hint.
+
+ A summary of the Framed-IP-Address Attribute 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 | Address
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Address (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 8 for Framed-IP-Address.
+
+ Length
+
+ 6
+
+ Address
+
+ The Address field is four octets. The value 0xFFFFFFFF indicates
+ that the NAS Should allow the user to select an address (e.g.
+ Negotiated). The value 0xFFFFFFFE indicates that the NAS should
+ select an address for the user (e.g. Assigned from a pool of
+ addresses kept by the NAS). Other valid values indicate that the
+ NAS should use that value as the user's IP address.
+
+5.9. Framed-IP-Netmask
+
+ Description
+
+ This Attribute indicates the IP netmask to be configured for the
+ user when the user is a router to a network. It MAY be used in
+ Access-Accept packets. It MAY be used in an Access-Request packet
+ as a hint by the NAS to the server that it would prefer that
+ netmask, but the server is not required to honor the hint.
+
+
+
+
+Rigney, et al. Standards Track [Page 34]
+
+RFC 2865 RADIUS June 2000
+
+
+ A summary of the Framed-IP-Netmask Attribute 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 | Address
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Address (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 9 for Framed-IP-Netmask.
+
+ Length
+
+ 6
+
+ Address
+
+ The Address field is four octets specifying the IP netmask of the
+ user.
+
+5.10. Framed-Routing
+
+ Description
+
+ This Attribute indicates the routing method for the user, when the
+ user is a router to a network. It is only used in Access-Accept
+ packets.
+
+ A summary of the Framed-Routing Attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 10 for Framed-Routing.
+
+
+
+
+
+Rigney, et al. Standards Track [Page 35]
+
+RFC 2865 RADIUS June 2000
+
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets.
+
+ 0 None
+ 1 Send routing packets
+ 2 Listen for routing packets
+ 3 Send and Listen
+
+5.11. Filter-Id
+
+ Description
+
+ This Attribute indicates the name of the filter list for this
+ user. Zero or more Filter-Id attributes MAY be sent in an
+ Access-Accept packet.
+
+ Identifying a filter list by name allows the filter to be used on
+ different NASes without regard to filter-list implementation
+ details.
+
+ A summary of the Filter-Id Attribute 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ | Type | Length | Text ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Type
+
+ 11 for Filter-Id.
+
+ Length
+
+ >= 3
+
+ Text
+
+ The Text field is one 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 UTF-8 encoded 10646 [7] characters.
+
+
+
+Rigney, et al. Standards Track [Page 36]
+
+RFC 2865 RADIUS June 2000
+
+
+5.12. Framed-MTU
+
+ Description
+
+ This Attribute indicates the Maximum Transmission Unit to be
+ configured for the user, when it is not negotiated by some other
+ means (such as PPP). It MAY be used in Access-Accept packets. It
+ MAY be used in an Access-Request packet as a hint by the NAS to
+ the server that it would prefer that value, but the server is not
+ required to honor the hint.
+
+ A summary of the Framed-MTU Attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 12 for Framed-MTU.
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets. Despite the size of the field,
+ values range from 64 to 65535.
+
+5.13. Framed-Compression
+
+ Description
+
+ This Attribute indicates a compression protocol to be used for the
+ link. It MAY be used in Access-Accept packets. It MAY be used in
+ an Access-Request packet as a hint to the server that the NAS
+ would prefer to use that compression, but the server is not
+ required to honor the hint.
+
+ More than one compression protocol Attribute MAY be sent. It is
+ the responsibility of the NAS to apply the proper compression
+ protocol to appropriate link traffic.
+
+
+
+Rigney, et al. Standards Track [Page 37]
+
+RFC 2865 RADIUS June 2000
+
+
+ A summary of the Framed-Compression Attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 13 for Framed-Compression.
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets.
+
+ 0 None
+ 1 VJ TCP/IP header compression [10]
+ 2 IPX header compression
+ 3 Stac-LZS compression
+
+5.14. Login-IP-Host
+
+ Description
+
+ This Attribute indicates the system with which to connect the user,
+ when the Login-Service Attribute is included. It MAY be used in
+ Access-Accept packets. It MAY be used in an Access-Request packet as
+ a hint to the server that the NAS would prefer to use that host, but
+ the server is not required to honor the hint.
+
+ A summary of the Login-IP-Host Attribute format is shown below. The
+ fields are transmitted from left to right.
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et al. Standards Track [Page 38]
+
+RFC 2865 RADIUS June 2000
+
+
+ 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 | Address
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Address (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 14 for Login-IP-Host.
+
+ Length
+
+ 6
+
+ Address
+
+ The Address field is four octets. The value 0xFFFFFFFF indicates
+ that the NAS SHOULD allow the user to select an address. The
+ value 0 indicates that the NAS SHOULD select a host to connect the
+ user to. Other values indicate the address the NAS SHOULD connect
+ the user to.
+
+5.15. Login-Service
+
+ Description
+
+ This Attribute indicates the service to use to connect the user to
+ the login host. It is only used in Access-Accept packets.
+
+ A summary of the Login-Service Attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 15 for Login-Service.
+
+
+
+
+
+
+Rigney, et al. Standards Track [Page 39]
+
+RFC 2865 RADIUS June 2000
+
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets.
+
+ 0 Telnet
+ 1 Rlogin
+ 2 TCP Clear
+ 3 PortMaster (proprietary)
+ 4 LAT
+ 5 X25-PAD
+ 6 X25-T3POS
+ 8 TCP Clear Quiet (suppresses any NAS-generated connect string)
+
+5.16. Login-TCP-Port
+
+ Description
+
+ This Attribute indicates the TCP port with which the user is to be
+ connected, when the Login-Service Attribute is also present. It
+ is only used in Access-Accept packets.
+
+ A summary of the Login-TCP-Port Attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 16 for Login-TCP-Port.
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets. Despite the size of the field,
+ values range from 0 to 65535.
+
+
+
+Rigney, et al. Standards Track [Page 40]
+
+RFC 2865 RADIUS June 2000
+
+
+5.17. (unassigned)
+
+ Description
+
+ ATTRIBUTE TYPE 17 HAS NOT BEEN ASSIGNED.
+
+5.18. Reply-Message
+
+ Description
+
+ This Attribute indicates text which MAY be displayed to the user.
+
+ When used in an Access-Accept, it is the success message.
+
+ When used in an Access-Reject, it is the failure message. It MAY
+ indicate a dialog message to prompt the user before another
+ Access-Request attempt.
+
+ When used in an Access-Challenge, it MAY indicate a dialog message
+ to prompt the user for a response.
+
+ Multiple Reply-Message's MAY be included and if any are displayed,
+ they MUST be displayed in the same order as they appear in the
+ packet.
+
+ A summary of the Reply-Message Attribute 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ | Type | Length | Text ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Type
+
+ 18 for Reply-Message.
+
+ Length
+
+ >= 3
+
+ Text
+
+ The Text field is one 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 UTF-8 encoded 10646 [7] characters.
+
+
+
+Rigney, et al. Standards Track [Page 41]
+
+RFC 2865 RADIUS June 2000
+
+
+5.19. Callback-Number
+
+ Description
+
+ This Attribute indicates a dialing string to be used for callback.
+ It MAY be used in Access-Accept packets. It MAY be used in an
+ Access-Request packet as a hint to the server that a Callback
+ service is desired, but the server is not required to honor the
+ hint.
+
+ A summary of the Callback-Number Attribute 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ | Type | Length | String ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Type
+
+ 19 for Callback-Number.
+
+ Length
+
+ >= 3
+
+ String
+
+ The String field is one or more octets. The actual format of the
+ information is site or application specific, and a robust
+ implementation SHOULD support the field as undistinguished octets.
+
+ The codification of the range of allowed usage of this field is
+ outside the scope of this specification.
+
+5.20. Callback-Id
+
+ Description
+
+ This Attribute indicates the name of a place to be called, to be
+ interpreted by the NAS. It MAY be used in Access-Accept packets.
+
+
+
+
+
+
+
+
+
+Rigney, et al. Standards Track [Page 42]
+
+RFC 2865 RADIUS June 2000
+
+
+ A summary of the Callback-Id Attribute 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ | Type | Length | String ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Type
+
+ 20 for Callback-Id.
+
+ Length
+
+ >= 3
+
+ String
+
+ The String field is one or more octets. The actual format of the
+ information is site or application specific, and a robust
+ implementation SHOULD support the field as undistinguished octets.
+
+ The codification of the range of allowed usage of this field is
+ outside the scope of this specification.
+
+5.21. (unassigned)
+
+ Description
+
+ ATTRIBUTE TYPE 21 HAS NOT BEEN ASSIGNED.
+
+5.22. Framed-Route
+
+ Description
+
+ This Attribute provides routing information to be configured for
+ the user on the NAS. It is used in the Access-Accept packet and
+ can appear multiple times.
+
+ A summary of the Framed-Route Attribute 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 | Text ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+
+
+Rigney, et al. Standards Track [Page 43]
+
+RFC 2865 RADIUS June 2000
+
+
+ Type
+
+ 22 for Framed-Route.
+
+ Length
+
+ >= 3
+
+ Text
+
+ The Text field is one 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 UTF-8 encoded 10646 [7] characters.
+
+ For IP routes, it SHOULD contain a destination prefix in dotted
+ quad form optionally followed by a slash and a decimal length
+ specifier stating how many high order bits of the prefix to use.
+ That is followed by a space, a gateway address in dotted quad
+ form, a space, and one or more metrics separated by spaces. For
+ example, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400". The length
+ specifier may be omitted, in which case it defaults to 8 bits for
+ class A prefixes, 16 bits for class B prefixes, and 24 bits for
+ class C prefixes. For example, "192.168.1.0 192.168.1.1 1".
+
+ Whenever the gateway address is specified as "0.0.0.0" the IP
+ address of the user SHOULD be used as the gateway address.
+
+5.23. Framed-IPX-Network
+
+ Description
+
+ This Attribute indicates the IPX Network number to be configured
+ for the user. It is used in Access-Accept packets.
+
+ A summary of the Framed-IPX-Network Attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+Rigney, et al. Standards Track [Page 44]
+
+RFC 2865 RADIUS June 2000
+
+
+ Type
+
+ 23 for Framed-IPX-Network.
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets. The value 0xFFFFFFFE indicates
+ that the NAS should select an IPX network for the user (e.g.
+ assigned from a pool of one or more IPX networks kept by the NAS).
+ Other values should be used as the IPX network for the link to the
+ user.
+
+5.24. State
+
+ Description
+
+ This Attribute is available to be sent by the server to the client
+ in an Access-Challenge and MUST be sent unmodified from the client
+ to the server in the new Access-Request reply to that challenge,
+ if any.
+
+ This Attribute is available to be sent by the server to the client
+ in an Access-Accept that also includes a Termination-Action
+ Attribute with the value of RADIUS-Request. If the NAS performs
+ the Termination-Action by sending a new Access-Request upon
+ termination of the current session, it MUST include the State
+ attribute unchanged in that Access-Request.
+
+ In either usage, the client MUST NOT interpret the attribute
+ locally. A packet must have only zero or one State Attribute.
+ Usage of the State Attribute is implementation dependent.
+
+ A summary of the State Attribute 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ | Type | Length | String ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Type
+
+ 24 for State.
+
+
+
+Rigney, et al. Standards Track [Page 45]
+
+RFC 2865 RADIUS June 2000
+
+
+ Length
+
+ >= 3
+
+ String
+
+ The String field is one or more octets. The actual format of the
+ information is site or application specific, and a robust
+ implementation SHOULD support the field as undistinguished octets.
+
+ The codification of the range of allowed usage of this field is
+ outside the scope of this specification.
+
+5.25. Class
+
+ Description
+
+ This Attribute is available to be sent by the server to the client
+ in an Access-Accept and SHOULD be sent unmodified by the client to
+ the accounting server as part of the Accounting-Request packet if
+ accounting is supported. The client MUST NOT interpret the
+ attribute locally.
+
+ A summary of the Class Attribute 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ | Type | Length | String ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Type
+
+ 25 for Class.
+
+ Length
+
+ >= 3
+
+ String
+
+ The String field is one or more octets. The actual format of the
+ information is site or application specific, and a robust
+ implementation SHOULD support the field as undistinguished octets.
+
+ The codification of the range of allowed usage of this field is
+ outside the scope of this specification.
+
+
+
+Rigney, et al. Standards Track [Page 46]
+
+RFC 2865 RADIUS June 2000
+
+
+5.26. Vendor-Specific
+
+ Description
+
+ This Attribute is available to allow vendors to support their own
+ extended Attributes not suitable for general usage. It MUST not
+ affect the operation of the RADIUS protocol.
+
+ Servers not equipped to interpret the vendor-specific information
+ sent by a client MUST ignore it (although it may be reported).
+ Clients which do not receive desired vendor-specific information
+ SHOULD make an attempt to operate without it, although they may do
+ so (and report they are doing so) in a degraded mode.
+
+ A summary of the Vendor-Specific Attribute 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 | Vendor-Id
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Vendor-Id (cont) | String...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Type
+
+ 26 for Vendor-Specific.
+
+ Length
+
+ >= 7
+
+ Vendor-Id
+
+ The high-order octet is 0 and the low-order 3 octets are the SMI
+ Network Management Private Enterprise Code of the Vendor in
+ network byte order, as defined in the "Assigned Numbers" RFC [6].
+
+ String
+
+ The String field is one or more octets. The actual format of the
+ information is site or application specific, and a robust
+ implementation SHOULD support the field as undistinguished octets.
+
+ The codification of the range of allowed usage of this field is
+ outside the scope of this specification.
+
+
+
+
+Rigney, et al. Standards Track [Page 47]
+
+RFC 2865 RADIUS June 2000
+
+
+ It SHOULD be encoded as a sequence of vendor type / vendor length
+ / value fields, as follows. The Attribute-Specific field is
+ dependent on the vendor's definition of that attribute. An
+ example encoding of the Vendor-Specific attribute using this
+ method 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Vendor-Id
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Vendor-Id (cont) | Vendor type | Vendor length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Attribute-Specific...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Multiple subattributes MAY be encoded within a single Vendor-
+ Specific attribute, although they do not have to be.
+
+5.27. Session-Timeout
+
+ Description
+
+ This Attribute sets the maximum number of seconds of service to be
+ provided to the user before termination of the session or prompt.
+ This Attribute is available to be sent by the server to the client
+ in an Access-Accept or Access-Challenge.
+
+ A summary of the Session-Timeout Attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 27 for Session-Timeout.
+
+ Length
+
+ 6
+
+
+
+
+
+Rigney, et al. Standards Track [Page 48]
+
+RFC 2865 RADIUS June 2000
+
+
+ Value
+
+ The field is 4 octets, containing a 32-bit unsigned integer with
+ the maximum number of seconds this user should be allowed to
+ remain connected by the NAS.
+
+5.28. Idle-Timeout
+
+ Description
+
+ This Attribute sets the maximum number of consecutive seconds of
+ idle connection allowed to the user before termination of the
+ session or prompt. This Attribute is available to be sent by the
+ server to the client in an Access-Accept or Access-Challenge.
+
+ A summary of the Idle-Timeout Attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 28 for Idle-Timeout.
+
+ Length
+
+ 6
+
+ Value
+
+ The field is 4 octets, containing a 32-bit unsigned integer with
+ the maximum number of consecutive seconds of idle time this user
+ should be permitted before being disconnected by the NAS.
+
+5.29. Termination-Action
+
+ Description
+
+ This Attribute indicates what action the NAS should take when the
+ specified service is completed. It is only used in Access-Accept
+ packets.
+
+
+
+
+Rigney, et al. Standards Track [Page 49]
+
+RFC 2865 RADIUS June 2000
+
+
+ A summary of the Termination-Action Attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 29 for Termination-Action.
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets.
+
+ 0 Default
+ 1 RADIUS-Request
+
+ If the Value is set to RADIUS-Request, upon termination of the
+ specified service the NAS MAY send a new Access-Request to the
+ RADIUS server, including the State attribute if any.
+
+5.30. Called-Station-Id
+
+ Description
+
+ This Attribute allows the NAS to send in the Access-Request packet
+ the phone number that the user called, using Dialed Number
+ Identification (DNIS) or similar technology. Note that this may
+ be different from the phone number the call comes in on. It is
+ only used in Access-Request packets.
+
+ A summary of the Called-Station-Id Attribute 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ | Type | Length | String ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+
+
+Rigney, et al. Standards Track [Page 50]
+
+RFC 2865 RADIUS June 2000
+
+
+ Type
+
+ 30 for Called-Station-Id.
+
+ Length
+
+ >= 3
+
+ String
+
+ The String field is one or more octets, containing the phone
+ number that the user's call came in on.
+
+ The actual format of the information is site or application
+ specific. UTF-8 encoded 10646 [7] characters are recommended, but
+ a robust implementation SHOULD support the field as
+ undistinguished octets.
+
+ The codification of the range of allowed usage of this field is
+ outside the scope of this specification.
+
+5.31. Calling-Station-Id
+
+ Description
+
+ This Attribute allows the NAS to send in the Access-Request packet
+ the phone number that the call came from, using Automatic Number
+ Identification (ANI) or similar technology. It is only used in
+ Access-Request packets.
+
+ A summary of the Calling-Station-Id Attribute 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ | Type | Length | String ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Type
+
+ 31 for Calling-Station-Id.
+
+ Length
+
+ >= 3
+
+
+
+
+
+Rigney, et al. Standards Track [Page 51]
+
+RFC 2865 RADIUS June 2000
+
+
+ String
+
+ The String field is one or more octets, containing the phone
+ number that the user placed the call from.
+
+ The actual format of the information is site or application
+ specific. UTF-8 encoded 10646 [7] characters are recommended, but
+ a robust implementation SHOULD support the field as
+ undistinguished octets.
+
+ The codification of the range of allowed usage of this field is
+ outside the scope of this specification.
+
+5.32. NAS-Identifier
+
+ Description
+
+ This Attribute contains a string identifying the NAS originating
+ the Access-Request. It is only used in Access-Request packets.
+ Either NAS-IP-Address or NAS-Identifier MUST be present in an
+ Access-Request packet.
+
+ Note that NAS-Identifier MUST NOT be used to select the shared
+ secret used to authenticate the request. The source IP address of
+ the Access-Request packet MUST be used to select the shared
+ secret.
+
+ A summary of the NAS-Identifier Attribute 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ | Type | Length | String ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Type
+
+ 32 for NAS-Identifier.
+
+ Length
+
+ >= 3
+
+
+
+
+
+
+
+
+Rigney, et al. Standards Track [Page 52]
+
+RFC 2865 RADIUS June 2000
+
+
+ String
+
+ The String field is one or more octets, and should be unique to
+ the NAS within the scope of the RADIUS server. For example, a
+ fully qualified domain name would be suitable as a NAS-Identifier.
+
+ The actual format of the information is site or application
+ specific, and a robust implementation SHOULD support the field as
+ undistinguished octets.
+
+ The codification of the range of allowed usage of this field is
+ outside the scope of this specification.
+
+5.33. Proxy-State
+
+ Description
+
+ This Attribute is available to be sent by a proxy server to
+ another server when forwarding an Access-Request and MUST be
+ returned unmodified in the Access-Accept, Access-Reject or
+ Access-Challenge. When the proxy server receives the response to
+ its request, it MUST remove its own Proxy-State (the last Proxy-
+ State in the packet) before forwarding the response to the NAS.
+
+ If a Proxy-State Attribute is added to a packet when forwarding
+ the packet, the Proxy-State Attribute MUST be added after any
+ existing Proxy-State attributes.
+
+ The content of any Proxy-State other than the one added by the
+ current server should be treated as opaque octets and MUST NOT
+ affect operation of the protocol.
+
+ Usage of the Proxy-State Attribute is implementation dependent. A
+ description of its function is outside the scope of this
+ specification.
+
+ A summary of the Proxy-State Attribute 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ | Type | Length | String ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Type
+
+ 33 for Proxy-State.
+
+
+
+Rigney, et al. Standards Track [Page 53]
+
+RFC 2865 RADIUS June 2000
+
+
+ Length
+
+ >= 3
+
+ String
+
+ The String field is one or more octets. The actual format of the
+ information is site or application specific, and a robust
+ implementation SHOULD support the field as undistinguished octets.
+
+ The codification of the range of allowed usage of this field is
+ outside the scope of this specification.
+
+5.34. Login-LAT-Service
+
+ Description
+
+ This Attribute indicates the system with which the user is to be
+ connected by LAT. It MAY be used in Access-Accept packets, but
+ only when LAT is specified as the Login-Service. It MAY be used
+ in an Access-Request packet as a hint to the server, but the
+ server is not required to honor the hint.
+
+ Administrators use the service attribute when dealing with
+ clustered systems, such as a VAX or Alpha cluster. In such an
+ environment several different time sharing hosts share the same
+ resources (disks, printers, etc.), and administrators often
+ configure each to offer access (service) to each of the shared
+ resources. In this case, each host in the cluster advertises its
+ services through LAT broadcasts.
+
+ Sophisticated users often know which service providers (machines)
+ are faster and tend to use a node name when initiating a LAT
+ connection. Alternately, some administrators want particular
+ users to use certain machines as a primitive form of load
+ balancing (although LAT knows how to do load balancing itself).
+
+ A summary of the Login-LAT-Service Attribute 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ | Type | Length | String ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+
+
+
+
+
+Rigney, et al. Standards Track [Page 54]
+
+RFC 2865 RADIUS June 2000
+
+
+ Type
+
+ 34 for Login-LAT-Service.
+
+ Length
+
+ >= 3
+
+ String
+
+ The String field is one or more octets, and contains the identity
+ of the LAT service to use. The LAT Architecture allows this
+ string to contain $ (dollar), - (hyphen), . (period), _
+ (underscore), numerics, upper and lower case alphabetics, and the
+ ISO Latin-1 character set extension [11]. All LAT string
+ comparisons are case insensitive.
+
+5.35. Login-LAT-Node
+
+ Description
+
+ This Attribute indicates the Node with which the user is to be
+ automatically connected by LAT. It MAY be used in Access-Accept
+ packets, but only when LAT is specified as the Login-Service. It
+ MAY be used in an Access-Request packet as a hint to the server,
+ but the server is not required to honor the hint.
+
+ A summary of the Login-LAT-Node Attribute 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ | Type | Length | String ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Type
+
+ 35 for Login-LAT-Node.
+
+ Length
+
+ >= 3
+
+
+
+
+
+
+
+
+Rigney, et al. Standards Track [Page 55]
+
+RFC 2865 RADIUS June 2000
+
+
+ String
+
+ The String field is one or more octets, and contains the identity
+ of the LAT Node to connect the user to. The LAT Architecture
+ allows this string to contain $ (dollar), - (hyphen), . (period),
+ _ (underscore), numerics, upper and lower case alphabetics, and
+ the ISO Latin-1 character set extension. All LAT string
+ comparisons are case insensitive.
+
+5.36. Login-LAT-Group
+
+ Description
+
+ This Attribute contains a string identifying the LAT group codes
+ which this user is authorized to use. It MAY be used in Access-
+ Accept packets, but only when LAT is specified as the Login-
+ Service. It MAY be used in an Access-Request packet as a hint to
+ the server, but the server is not required to honor the hint.
+
+ LAT supports 256 different group codes, which LAT uses as a form
+ of access rights. LAT encodes the group codes as a 256 bit
+ bitmap.
+
+ Administrators can assign one or more of the group code bits at
+ the LAT service provider; it will only accept LAT connections that
+ have these group codes set in the bit map. The administrators
+ assign a bitmap of authorized group codes to each user; LAT gets
+ these from the operating system, and uses these in its requests to
+ the service providers.
+
+ A summary of the Login-LAT-Group Attribute 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ | Type | Length | String ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Type
+
+ 36 for Login-LAT-Group.
+
+ Length
+
+ 34
+
+
+
+
+
+Rigney, et al. Standards Track [Page 56]
+
+RFC 2865 RADIUS June 2000
+
+
+ String
+
+ The String field is a 32 octet bit map, most significant octet
+ first. A robust implementation SHOULD support the field as
+ undistinguished octets.
+
+ The codification of the range of allowed usage of this field is
+ outside the scope of this specification.
+
+5.37. Framed-AppleTalk-Link
+
+ Description
+
+ This Attribute indicates the AppleTalk network number which should
+ be used for the serial link to the user, which is another
+ AppleTalk router. It is only used in Access-Accept packets. It
+ is never used when the user is not another router.
+
+ A summary of the Framed-AppleTalk-Link Attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 37 for Framed-AppleTalk-Link.
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets. Despite the size of the field,
+ values range from 0 to 65535. The special value of 0 indicates
+ that this is an unnumbered serial link. A value of 1-65535 means
+ that the serial line between the NAS and the user should be
+ assigned that value as an AppleTalk network number.
+
+
+
+
+
+
+
+Rigney, et al. Standards Track [Page 57]
+
+RFC 2865 RADIUS June 2000
+
+
+5.38. Framed-AppleTalk-Network
+
+ Description
+
+ This Attribute indicates the AppleTalk Network number which the
+ NAS should probe to allocate an AppleTalk node for the user. It
+ is only used in Access-Accept packets. It is never used when the
+ user is another router. Multiple instances of this Attribute
+ indicate that the NAS may probe using any of the network numbers
+ specified.
+
+ A summary of the Framed-AppleTalk-Network Attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 38 for Framed-AppleTalk-Network.
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets. Despite the size of the field,
+ values range from 0 to 65535. The special value 0 indicates that
+ the NAS should assign a network for the user, using its default
+ cable range. A value between 1 and 65535 (inclusive) indicates
+ the AppleTalk Network the NAS should probe to find an address for
+ the user.
+
+5.39. Framed-AppleTalk-Zone
+
+ Description
+
+ This Attribute indicates the AppleTalk Default Zone to be used for
+ this user. It is only used in Access-Accept packets. Multiple
+ instances of this attribute in the same packet are not allowed.
+
+
+
+
+
+Rigney, et al. Standards Track [Page 58]
+
+RFC 2865 RADIUS June 2000
+
+
+ A summary of the Framed-AppleTalk-Zone Attribute 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 4
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ | Type | Length | String ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Type
+
+ 39 for Framed-AppleTalk-Zone.
+
+ Length
+
+ >= 3
+
+ String
+
+ The name of the Default AppleTalk Zone to be used for this user.
+ A robust implementation SHOULD support the field as
+ undistinguished octets.
+
+ The codification of the range of allowed usage of this field is
+ outside the scope of this specification.
+
+5.40. CHAP-Challenge
+
+ Description
+
+ This Attribute contains the CHAP Challenge sent by the NAS to a
+ PPP Challenge-Handshake Authentication Protocol (CHAP) user. It
+ is only used in Access-Request packets.
+
+ If the CHAP challenge value is 16 octets long it MAY be placed in
+ the Request Authenticator field instead of using this attribute.
+
+ A summary of the CHAP-Challenge Attribute 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 | String...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+
+
+
+
+
+Rigney, et al. Standards Track [Page 59]
+
+RFC 2865 RADIUS June 2000
+
+
+ Type
+
+ 60 for CHAP-Challenge.
+
+ Length
+
+ >= 7
+
+ String
+
+ The String field contains the CHAP Challenge.
+
+5.41. NAS-Port-Type
+
+ Description
+
+ This Attribute indicates the type of the physical port of the NAS
+ which is authenticating the user. It can be used instead of or in
+ addition to the NAS-Port (5) attribute. It is only used in
+ Access-Request packets. Either NAS-Port (5) or NAS-Port-Type or
+ both SHOULD be present in an Access-Request packet, if the NAS
+ differentiates among its ports.
+
+ A summary of the NAS-Port-Type Attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 61 for NAS-Port-Type.
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets. "Virtual" refers to a connection
+ to the NAS via some transport protocol, instead of through a
+ physical port. For example, if a user telnetted into a NAS to
+
+
+
+
+Rigney, et al. Standards Track [Page 60]
+
+RFC 2865 RADIUS June 2000
+
+
+ authenticate himself as an Outbound-User, the Access-Request might
+ include NAS-Port-Type = Virtual as a hint to the RADIUS server
+ that the user was not on a physical port.
+
+ 0 Async
+ 1 Sync
+ 2 ISDN Sync
+ 3 ISDN Async V.120
+ 4 ISDN Async V.110
+ 5 Virtual
+ 6 PIAFS
+ 7 HDLC Clear Channel
+ 8 X.25
+ 9 X.75
+ 10 G.3 Fax
+ 11 SDSL - Symmetric DSL
+ 12 ADSL-CAP - Asymmetric DSL, Carrierless Amplitude Phase
+ Modulation
+ 13 ADSL-DMT - Asymmetric DSL, Discrete Multi-Tone
+ 14 IDSL - ISDN Digital Subscriber Line
+ 15 Ethernet
+ 16 xDSL - Digital Subscriber Line of unknown type
+ 17 Cable
+ 18 Wireless - Other
+ 19 Wireless - IEEE 802.11
+
+ PIAFS is a form of wireless ISDN commonly used in Japan, and
+ stands for PHS (Personal Handyphone System) Internet Access Forum
+ Standard (PIAFS).
+
+5.42. Port-Limit
+
+ Description
+
+ This Attribute sets the maximum number of ports to be provided to
+ the user by the NAS. This Attribute MAY be sent by the server to
+ the client in an Access-Accept packet. It is intended for use in
+ conjunction with Multilink PPP [12] or similar uses. It MAY also
+ be sent by the NAS to the server as a hint that that many ports
+ are desired for use, but the server is not required to honor the
+ hint.
+
+ A summary of the Port-Limit Attribute format is shown below. The
+ fields are transmitted from left to right.
+
+
+
+
+
+
+
+Rigney, et al. Standards Track [Page 61]
+
+RFC 2865 RADIUS June 2000
+
+
+ 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 62 for Port-Limit.
+
+ Length
+
+ 6
+
+ Value
+
+ The field is 4 octets, containing a 32-bit unsigned integer with
+ the maximum number of ports this user should be allowed to connect
+ to on the NAS.
+
+5.43. Login-LAT-Port
+
+ Description
+
+ This Attribute indicates the Port with which the user is to be
+ connected by LAT. It MAY be used in Access-Accept packets, but
+ only when LAT is specified as the Login-Service. It MAY be used
+ in an Access-Request packet as a hint to the server, but the
+ server is not required to honor the hint.
+
+ A summary of the Login-LAT-Port Attribute 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ | Type | Length | String ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Type
+
+ 63 for Login-LAT-Port.
+
+ Length
+
+ >= 3
+
+
+
+Rigney, et al. Standards Track [Page 62]
+
+RFC 2865 RADIUS June 2000
+
+
+ String
+
+ The String field is one or more octets, and contains the identity
+ of the LAT port to use. The LAT Architecture allows this string
+ to contain $ (dollar), - (hyphen), . (period), _ (underscore),
+ numerics, upper and lower case alphabetics, and the ISO Latin-1
+ character set extension. All LAT string comparisons are case
+ insensitive.
+
+5.44. Table of Attributes
+
+ The following table provides a guide to which attributes may be found
+ in which kinds of packets, and in what quantity.
+
+ Request Accept Reject Challenge # Attribute
+ 0-1 0-1 0 0 1 User-Name
+ 0-1 0 0 0 2 User-Password [Note 1]
+ 0-1 0 0 0 3 CHAP-Password [Note 1]
+ 0-1 0 0 0 4 NAS-IP-Address [Note 2]
+ 0-1 0 0 0 5 NAS-Port
+ 0-1 0-1 0 0 6 Service-Type
+ 0-1 0-1 0 0 7 Framed-Protocol
+ 0-1 0-1 0 0 8 Framed-IP-Address
+ 0-1 0-1 0 0 9 Framed-IP-Netmask
+ 0 0-1 0 0 10 Framed-Routing
+ 0 0+ 0 0 11 Filter-Id
+ 0-1 0-1 0 0 12 Framed-MTU
+ 0+ 0+ 0 0 13 Framed-Compression
+ 0+ 0+ 0 0 14 Login-IP-Host
+ 0 0-1 0 0 15 Login-Service
+ 0 0-1 0 0 16 Login-TCP-Port
+ 0 0+ 0+ 0+ 18 Reply-Message
+ 0-1 0-1 0 0 19 Callback-Number
+ 0 0-1 0 0 20 Callback-Id
+ 0 0+ 0 0 22 Framed-Route
+ 0 0-1 0 0 23 Framed-IPX-Network
+ 0-1 0-1 0 0-1 24 State [Note 1]
+ 0 0+ 0 0 25 Class
+ 0+ 0+ 0 0+ 26 Vendor-Specific
+ 0 0-1 0 0-1 27 Session-Timeout
+ 0 0-1 0 0-1 28 Idle-Timeout
+ 0 0-1 0 0 29 Termination-Action
+ 0-1 0 0 0 30 Called-Station-Id
+ 0-1 0 0 0 31 Calling-Station-Id
+ 0-1 0 0 0 32 NAS-Identifier [Note 2]
+ 0+ 0+ 0+ 0+ 33 Proxy-State
+ 0-1 0-1 0 0 34 Login-LAT-Service
+ 0-1 0-1 0 0 35 Login-LAT-Node
+
+
+
+Rigney, et al. Standards Track [Page 63]
+
+RFC 2865 RADIUS June 2000
+
+
+ 0-1 0-1 0 0 36 Login-LAT-Group
+ 0 0-1 0 0 37 Framed-AppleTalk-Link
+ 0 0+ 0 0 38 Framed-AppleTalk-Network
+ 0 0-1 0 0 39 Framed-AppleTalk-Zone
+ 0-1 0 0 0 60 CHAP-Challenge
+ 0-1 0 0 0 61 NAS-Port-Type
+ 0-1 0-1 0 0 62 Port-Limit
+ 0-1 0-1 0 0 63 Login-LAT-Port
+ Request Accept Reject Challenge # Attribute
+
+ [Note 1] An Access-Request MUST contain either a User-Password or a
+ CHAP-Password or State. An Access-Request MUST NOT contain both a
+ User-Password and a CHAP-Password. If future extensions allow other
+ kinds of authentication information to be conveyed, the attribute for
+ that can be used in an Access-Request instead of User-Password or
+ CHAP-Password.
+
+ [Note 2] An Access-Request MUST contain either a NAS-IP-Address or a
+ NAS-Identifier (or both).
+
+ The following table defines the meaning of the above table entries.
+
+0 This attribute MUST NOT be present in packet.
+0+ Zero or more instances of this attribute MAY be present in packet.
+0-1 Zero or one instance of this attribute MAY be present in packet.
+1 Exactly one instance of this attribute MUST be present in packet.
+
+6. IANA Considerations
+
+ This section provides guidance to the Internet Assigned Numbers
+ Authority (IANA) regarding registration of values related to the
+ RADIUS protocol, in accordance with BCP 26 [13].
+
+ There are three name spaces in RADIUS that require registration:
+ Packet Type Codes, Attribute Types, and Attribute Values (for certain
+ Attributes).
+
+ RADIUS is not intended as a general-purpose Network Access Server
+ (NAS) management protocol, and allocations should not be made for
+ purposes unrelated to Authentication, Authorization or Accounting.
+
+6.1. Definition of Terms
+
+ The following terms are used here with the meanings defined in
+ BCP 26: "name space", "assigned value", "registration".
+
+
+
+
+
+
+Rigney, et al. Standards Track [Page 64]
+
+RFC 2865 RADIUS June 2000
+
+
+ The following policies are used here with the meanings defined in
+ BCP 26: "Private Use", "First Come First Served", "Expert Review",
+ "Specification Required", "IETF Consensus", "Standards Action".
+
+6.2. Recommended Registration Policies
+
+ For registration requests where a Designated Expert should be
+ consulted, the IESG Area Director for Operations should appoint the
+ Designated Expert.
+
+ For registration requests requiring Expert Review, the ietf-radius
+ mailing list should be consulted.
+
+ Packet Type Codes have a range from 1 to 254, of which 1-5,11-13 have
+ been allocated. Because a new Packet Type has considerable impact on
+ interoperability, a new Packet Type Code requires Standards Action,
+ and should be allocated starting at 14.
+
+ Attribute Types have a range from 1 to 255, and are the scarcest
+ resource in RADIUS, thus must be allocated with care. Attributes
+ 1-53,55,60-88,90-91 have been allocated, with 17 and 21 available for
+ re-use. Attributes 17, 21, 54, 56-59, 89, 92-191 may be allocated
+ following Expert Review, with Specification Required. Release of
+ blocks of Attribute Types (more than 3 at a time for a given purpose)
+ should require IETF Consensus. It is recommended that attributes 17
+ and 21 be used only after all others are exhausted.
+
+ Note that RADIUS defines a mechanism for Vendor-Specific extensions
+ (Attribute 26) and the use of that should be encouraged instead of
+ allocation of global attribute types, for functions specific only to
+ one vendor's implementation of RADIUS, where no interoperability is
+ deemed useful.
+
+ As stated in the "Attributes" section above:
+
+ "[Attribute Type] Values 192-223 are reserved for experimental
+ use, values 224-240 are reserved for implementation-specific use,
+ and values 241-255 are reserved and should not be used."
+
+ Therefore Attribute values 192-240 are considered Private Use, and
+ values 241-255 require Standards Action.
+
+ Certain attributes (for example, NAS-Port-Type) in RADIUS define a
+ list of values to correspond with various meanings. There can be 4
+ billion (2^32) values for each attribute. Adding additional values to
+ the list can be done on a First Come, First Served basis by the IANA.
+
+
+
+
+
+Rigney, et al. Standards Track [Page 65]
+
+RFC 2865 RADIUS June 2000
+
+
+7. Examples
+
+ A few examples are presented to illustrate the flow of packets and
+ use of typical attributes. These examples are not intended to be
+ exhaustive, many others are possible. Hexadecimal dumps of the
+ example packets are given in network byte order, using the shared
+ secret "xyzzy5461".
+
+7.1. User Telnet to Specified Host
+
+ The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
+ RADIUS Server for a user named nemo logging in on port 3 with
+ password "arctangent".
+
+ The Request Authenticator is a 16 octet random number generated by
+ the NAS.
+
+ The User-Password is 16 octets of password padded at end with nulls,
+ XORed with MD5(shared secret|Request Authenticator).
+
+ 01 00 00 38 0f 40 3f 94 73 97 80 57 bd 83 d5 cb
+ 98 f4 22 7a 01 06 6e 65 6d 6f 02 12 0d be 70 8d
+ 93 d4 13 ce 31 96 e4 3f 78 2a 0a ee 04 06 c0 a8
+ 01 10 05 06 00 00 00 03
+
+ 1 Code = Access-Request (1)
+ 1 ID = 0
+ 2 Length = 56
+ 16 Request Authenticator
+
+ Attributes:
+ 6 User-Name = "nemo"
+ 18 User-Password
+ 6 NAS-IP-Address = 192.168.1.16
+ 6 NAS-Port = 3
+
+ The RADIUS server authenticates nemo, and sends an Access-Accept UDP
+ packet to the NAS telling it to telnet nemo to host 192.168.1.3.
+
+ The Response Authenticator is a 16-octet MD5 checksum of the code
+ (2), id (0), Length (38), the Request Authenticator from above, the
+ attributes in this reply, and the shared secret.
+
+
+
+
+
+
+
+
+
+Rigney, et al. Standards Track [Page 66]
+
+RFC 2865 RADIUS June 2000
+
+
+ 02 00 00 26 86 fe 22 0e 76 24 ba 2a 10 05 f6 bf
+ 9b 55 e0 b2 06 06 00 00 00 01 0f 06 00 00 00 00
+ 0e 06 c0 a8 01 03
+
+ 1 Code = Access-Accept (2)
+ 1 ID = 0 (same as in Access-Request)
+ 2 Length = 38
+ 16 Response Authenticator
+
+ Attributes:
+ 6 Service-Type (6) = Login (1)
+ 6 Login-Service (15) = Telnet (0)
+ 6 Login-IP-Host (14) = 192.168.1.3
+
+7.2. Framed User Authenticating with CHAP
+
+ The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
+ RADIUS Server for a user named flopsy logging in on port 20 with PPP,
+ authenticating using CHAP. The NAS sends along the Service-Type and
+ Framed-Protocol attributes as a hint to the RADIUS server that this
+ user is looking for PPP, although the NAS is not required to do so.
+
+ The Request Authenticator is a 16 octet random number generated by
+ the NAS, and is also used as the CHAP Challenge.
+
+ The CHAP-Password consists of a 1 octet CHAP ID, in this case 22,
+ followed by the 16 octet CHAP response.
+
+ 01 01 00 47 2a ee 86 f0 8d 0d 55 96 9c a5 97 8e
+ 0d 33 67 a2 01 08 66 6c 6f 70 73 79 03 13 16 e9
+ 75 57 c3 16 18 58 95 f2 93 ff 63 44 07 72 75 04
+ 06 c0 a8 01 10 05 06 00 00 00 14 06 06 00 00 00
+ 02 07 06 00 00 00 01
+
+ 1 Code = 1 (Access-Request)
+ 1 ID = 1
+ 2 Length = 71
+ 16 Request Authenticator
+
+ Attributes:
+ 8 User-Name (1) = "flopsy"
+ 19 CHAP-Password (3)
+ 6 NAS-IP-Address (4) = 192.168.1.16
+ 6 NAS-Port (5) = 20
+ 6 Service-Type (6) = Framed (2)
+ 6 Framed-Protocol (7) = PPP (1)
+
+
+
+
+
+Rigney, et al. Standards Track [Page 67]
+
+RFC 2865 RADIUS June 2000
+
+
+ The RADIUS server authenticates flopsy, and sends an Access-Accept
+ UDP packet to the NAS telling it to start PPP service and assign an
+ address for the user out of its dynamic address pool.
+
+ The Response Authenticator is a 16-octet MD5 checksum of the code
+ (2), id (1), Length (56), the Request Authenticator from above, the
+ attributes in this reply, and the shared secret.
+
+ 02 01 00 38 15 ef bc 7d ab 26 cf a3 dc 34 d9 c0
+ 3c 86 01 a4 06 06 00 00 00 02 07 06 00 00 00 01
+ 08 06 ff ff ff fe 0a 06 00 00 00 02 0d 06 00 00
+ 00 01 0c 06 00 00 05 dc
+
+ 1 Code = Access-Accept (2)
+ 1 ID = 1 (same as in Access-Request)
+ 2 Length = 56
+ 16 Response Authenticator
+
+ Attributes:
+ 6 Service-Type (6) = Framed (2)
+ 6 Framed-Protocol (7) = PPP (1)
+ 6 Framed-IP-Address (8) = 255.255.255.254
+ 6 Framed-Routing (10) = None (0)
+ 6 Framed-Compression (13) = VJ TCP/IP Header Compression (1)
+ 6 Framed-MTU (12) = 1500
+
+7.3. User with Challenge-Response card
+
+ The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
+ RADIUS Server for a user named mopsy logging in on port 7. The user
+ enters the dummy password "challenge" in this example. The challenge
+ and response generated by the smart card for this example are
+ "32769430" and "99101462".
+
+ The Request Authenticator is a 16 octet random number generated by
+ the NAS.
+
+ The User-Password is 16 octets of password, in this case "challenge",
+ padded at the end with nulls, XORed with MD5(shared secret|Request
+ Authenticator).
+
+ 01 02 00 39 f3 a4 7a 1f 6a 6d 76 71 0b 94 7a b9
+ 30 41 a0 39 01 07 6d 6f 70 73 79 02 12 33 65 75
+ 73 77 82 89 b5 70 88 5e 15 08 48 25 c5 04 06 c0
+ a8 01 10 05 06 00 00 00 07
+
+
+
+
+
+
+Rigney, et al. Standards Track [Page 68]
+
+RFC 2865 RADIUS June 2000
+
+
+ 1 Code = Access-Request (1)
+ 1 ID = 2
+ 2 Length = 57
+ 16 Request Authenticator
+
+ Attributes:
+ 7 User-Name (1) = "mopsy"
+ 18 User-Password (2)
+ 6 NAS-IP-Address (4) = 192.168.1.16
+ 6 NAS-Port (5) = 7
+
+ The RADIUS server decides to challenge mopsy, sending back a
+ challenge string and looking for a response. The RADIUS server
+ therefore and sends an Access-Challenge UDP packet to the NAS.
+
+ The Response Authenticator is a 16-octet MD5 checksum of the code
+ (11), id (2), length (78), the Request Authenticator from above, the
+ attributes in this reply, and the shared secret.
+
+ The Reply-Message is "Challenge 32769430. Enter response at prompt."
+
+ The State is a magic cookie to be returned along with user's
+ response; in this example 8 octets of data (33 32 37 36 39 34 33 30
+ in hex).
+
+ 0b 02 00 4e 36 f3 c8 76 4a e8 c7 11 57 40 3c 0c
+ 71 ff 9c 45 12 30 43 68 61 6c 6c 65 6e 67 65 20
+ 33 32 37 36 39 34 33 30 2e 20 20 45 6e 74 65 72
+ 20 72 65 73 70 6f 6e 73 65 20 61 74 20 70 72 6f
+ 6d 70 74 2e 18 0a 33 32 37 36 39 34 33 30
+
+ 1 Code = Access-Challenge (11)
+ 1 ID = 2 (same as in Access-Request)
+ 2 Length = 78
+ 16 Response Authenticator
+
+ Attributes:
+ 48 Reply-Message (18)
+ 10 State (24)
+
+ The user enters his response, and the NAS send a new Access-Request
+ with that response, and includes the State Attribute.
+
+ The Request Authenticator is a new 16 octet random number.
+
+ The User-Password is 16 octets of the user's response, in this case
+ "99101462", padded at the end with nulls, XORed with MD5(shared
+ secret|Request Authenticator).
+
+
+
+Rigney, et al. Standards Track [Page 69]
+
+RFC 2865 RADIUS June 2000
+
+
+ The state is the magic cookie from the Access-Challenge packet,
+ unchanged.
+
+ 01 03 00 43 b1 22 55 6d 42 8a 13 d0 d6 25 38 07
+ c4 57 ec f0 01 07 6d 6f 70 73 79 02 12 69 2c 1f
+ 20 5f c0 81 b9 19 b9 51 95 f5 61 a5 81 04 06 c0
+ a8 01 10 05 06 00 00 00 07 18 10 33 32 37 36 39
+ 34 33 30
+
+ 1 Code = Access-Request (1)
+ 1 ID = 3 (Note that this changes.)
+ 2 Length = 67
+ 16 Request Authenticator
+
+ Attributes:
+ 7 User-Name = "mopsy"
+ 18 User-Password
+ 6 NAS-IP-Address (4) = 192.168.1.16
+ 6 NAS-Port (5) = 7
+ 10 State (24)
+
+ The Response was incorrect (for the sake of example), so the RADIUS
+ server tells the NAS to reject the login attempt.
+
+ The Response Authenticator is a 16 octet MD5 checksum of the code
+ (3), id (3), length(20), the Request Authenticator from above, the
+ attributes in this reply (in this case, none), and the shared secret.
+
+ 03 03 00 14 a4 2f 4f ca 45 91 6c 4e 09 c8 34 0f
+ 9e 74 6a a0
+
+ 1 Code = Access-Reject (3)
+ 1 ID = 3 (same as in Access-Request)
+ 2 Length = 20
+ 16 Response Authenticator
+
+ Attributes:
+ (none, although a Reply-Message could be sent)
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et al. Standards Track [Page 70]
+
+RFC 2865 RADIUS June 2000
+
+
+8. Security Considerations
+
+ Security issues are the primary topic of this document.
+
+ In practice, within or associated with each RADIUS 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. 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 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 [14], but such a mechanism is outside the scope of this
+ specification.
+
+ Other distribution methods are currently undergoing research and
+ experimentation. The SNMP Security document [14] also has an
+ excellent overview of threats to network protocols.
+
+ The User-Password hiding mechanism described in Section 5.2 has not
+ been subjected to significant amounts of cryptanalysis in the
+ published literature. Some in the IETF community are concerned that
+ this method might not provide sufficient confidentiality protection
+ [15] to passwords transmitted using RADIUS. Users should evaluate
+ their threat environment and consider whether additional security
+ mechanisms should be employed.
+
+9. Change Log
+
+ The following changes have been made from RFC 2138:
+
+ Strings should use UTF-8 instead of US-ASCII and should be handled as
+ 8-bit data.
+
+ Integers and dates are now defined as 32 bit unsigned values.
+
+
+
+Rigney, et al. Standards Track [Page 71]
+
+RFC 2865 RADIUS June 2000
+
+
+ Updated list of attributes that can be included in Access-Challenge
+ to be consistent with the table of attributes.
+
+ User-Name mentions Network Access Identifiers.
+
+ User-Name may now be sent in Access-Accept for use with accounting
+ and Rlogin.
+
+ Values added for Service-Type, Login-Service, Framed-Protocol,
+ Framed-Compression, and NAS-Port-Type.
+
+ NAS-Port can now use all 32 bits.
+
+ Examples now include hexadecimal displays of the packets.
+
+ Source UDP port must be used in conjunction with the Request
+ Identifier when identifying duplicates.
+
+ Multiple subattributes may be allowed in a Vendor-Specific attribute.
+
+ An Access-Request is now required to contain either a NAS-IP-Address
+ or NAS-Identifier (or may contain both).
+
+ Added notes under "Operations" with more information on proxy,
+ retransmissions, and keep-alives.
+
+ If multiple Attributes with the same Type are present, the order of
+ Attributes with the same Type MUST be preserved by any proxies.
+
+ Clarified Proxy-State.
+
+ Clarified that Attributes must not depend on position within the
+ packet, as long as Attributes of the same type are kept in order.
+
+ Added IANA Considerations section.
+
+ Updated section on "Proxy" under "Operations".
+
+ Framed-MTU can now be sent in Access-Request as a hint.
+
+ Updated Security Considerations.
+
+ Text strings identified as a subset of string, to clarify use of
+ UTF-8.
+
+
+
+
+
+
+
+Rigney, et al. Standards Track [Page 72]
+
+RFC 2865 RADIUS June 2000
+
+
+10. References
+
+ [1] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
+ Authentication Dial In User Service (RADIUS)", RFC 2138, April
+ 1997.
+
+ [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March, 1997.
+
+ [3] Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm",
+ RFC 1321, April 1992.
+
+ [4] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
+ 1980.
+
+ [5] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
+
+ [6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
+ 1700, October 1994.
+
+ [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
+ 2279, January 1998.
+
+ [8] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC
+ 2486, January 1999.
+
+ [9] Kaufman, C., Perlman, R., and Speciner, M., "Network Security:
+ Private Communications in a Public World", Prentice Hall, March
+ 1995, ISBN 0-13-061466-1.
+
+ [10] Jacobson, V., "Compressing TCP/IP headers for low-speed serial
+ links", RFC 1144, February 1990.
+
+ [11] ISO 8859. International Standard -- Information Processing --
+ 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin
+ Alphabet No. 1, ISO 8859-1:1987.
+
+ [12] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T.
+ Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August
+ 1996.
+
+ [13] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
+ Considerations Section in RFCs", BCP 26, RFC 2434, October
+ 1998.
+
+ [14] Galvin, J., McCloghrie, K. and J. Davin, "SNMP Security
+ Protocols", RFC 1352, July 1992.
+
+
+
+
+Rigney, et al. Standards Track [Page 73]
+
+RFC 2865 RADIUS June 2000
+
+
+ [15] Dobbertin, H., "The Status of MD5 After a Recent Attack",
+ CryptoBytes Vol.2 No.2, Summer 1996.
+
+11. Acknowledgements
+
+ RADIUS was originally developed by Steve Willens of Livingston
+ Enterprises for their PortMaster series of Network Access Servers.
+
+12. Chair's Address
+
+ The working group can be contacted via the current chair:
+
+ Carl Rigney
+ Livingston Enterprises
+ 4464 Willow Road
+ Pleasanton, California 94588
+
+ Phone: +1 925 737 2100
+ EMail: cdr@telemancy.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et al. Standards Track [Page 74]
+
+RFC 2865 RADIUS June 2000
+
+
+13. Authors' Addresses
+
+ Questions about this memo can also be directed to:
+
+ Carl Rigney
+ Livingston Enterprises
+ 4464 Willow Road
+ Pleasanton, California 94588
+
+ Phone: +1 925 737 2100
+ EMail: cdr@telemancy.com
+
+
+ Allan C. Rubens
+ Merit Network, Inc.
+ 4251 Plymouth Road
+ Ann Arbor, Michigan 48105-2785
+
+ EMail: acr@merit.edu
+
+
+ William Allen Simpson
+ Daydreamer
+ Computer Systems Consulting Services
+ 1384 Fontaine
+ Madison Heights, Michigan 48071
+
+ EMail: wsimpson@greendragon.com
+
+
+ Steve Willens
+ Livingston Enterprises
+ 4464 Willow Road
+ Pleasanton, California 94588
+
+ EMail: steve@livingston.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et al. Standards Track [Page 75]
+
+RFC 2865 RADIUS June 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et al. Standards Track [Page 76]
+
diff --git a/rfc/rfc2866.txt b/rfc/rfc2866.txt
new file mode 100644
index 0000000..82da1dc
--- /dev/null
+++ b/rfc/rfc2866.txt
@@ -0,0 +1,1571 @@
+
+
+
+
+
+
+Network Working Group C. Rigney
+Request for Comments: 2866 Livingston
+Category: Informational June 2000
+Obsoletes: 2139
+
+
+ RADIUS Accounting
+
+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
+
+ This document describes a protocol for carrying accounting
+ information between a Network Access Server and a shared Accounting
+ Server.
+
+Implementation Note
+
+ This memo documents the RADIUS Accounting protocol. The early
+ deployment of RADIUS Accounting was done using UDP port number 1646,
+ which conflicts with the "sa-msg-port" service. The officially
+ assigned port number for RADIUS Accounting is 1813.
+
+Table of Contents
+
+ 1. Introduction .................................... 2
+ 1.1 Specification of Requirements ................. 3
+ 1.2 Terminology ................................... 3
+ 2. Operation ....................................... 4
+ 2.1 Proxy ......................................... 4
+ 3. Packet Format ................................... 5
+ 4. Packet Types ................................... 7
+ 4.1 Accounting-Request ............................ 8
+ 4.2 Accounting-Response ........................... 9
+ 5. Attributes ...................................... 10
+ 5.1 Acct-Status-Type .............................. 12
+ 5.2 Acct-Delay-Time ............................... 13
+ 5.3 Acct-Input-Octets ............................. 14
+ 5.4 Acct-Output-Octets ............................ 15
+ 5.5 Acct-Session-Id ............................... 15
+
+
+
+Rigney Informational [Page 1]
+
+RFC 2866 RADIUS Accounting June 2000
+
+
+ 5.6 Acct-Authentic ................................ 16
+ 5.7 Acct-Session-Time ............................. 17
+ 5.8 Acct-Input-Packets ............................ 18
+ 5.9 Acct-Output-Packets ........................... 18
+ 5.10 Acct-Terminate-Cause .......................... 19
+ 5.11 Acct-Multi-Session-Id ......................... 21
+ 5.12 Acct-Link-Count ............................... 22
+ 5.13 Table of Attributes ........................... 23
+ 6. IANA Considerations ............................. 25
+ 7. Security Considerations ......................... 25
+ 8. Change Log ...................................... 25
+ 9. References ...................................... 26
+ 10. Acknowledgements ................................ 26
+ 11. Chair's Address ................................. 26
+ 12. Author's Address ................................ 27
+ 13. Full Copyright Statement ........................ 28
+
+1. Introduction
+
+ Managing dispersed serial line and modem pools for large numbers of
+ users can create the need for significant administrative support.
+ Since modem pools are by definition a link to the outside world, they
+ require careful attention to security, authorization and accounting.
+ This can be best achieved by managing a single "database" of users,
+ which allows for authentication (verifying user name and password) as
+ well as configuration information detailing the type of service to
+ deliver to the user (for example, SLIP, PPP, telnet, rlogin).
+
+ The RADIUS (Remote Authentication Dial In User Service) document [2]
+ specifies the RADIUS protocol used for Authentication and
+ Authorization. This memo extends the use of the RADIUS protocol to
+ cover delivery of accounting information from the Network Access
+ Server (NAS) to a RADIUS accounting server.
+
+ This document obsoletes RFC 2139 [1]. A summary of the changes
+ between this document and RFC 2139 is available in the "Change Log"
+ appendix.
+
+ Key features of RADIUS Accounting are:
+
+ Client/Server Model
+
+ A Network Access Server (NAS) operates as a client of the
+ RADIUS accounting server. The client is responsible for
+ passing user accounting information to a designated RADIUS
+ accounting server.
+
+
+
+
+
+Rigney Informational [Page 2]
+
+RFC 2866 RADIUS Accounting June 2000
+
+
+ The RADIUS accounting server is responsible for receiving the
+ accounting request and returning a response to the client
+ indicating that it has successfully received the request.
+
+ The RADIUS accounting server can act as a proxy client to
+ other kinds of accounting servers.
+
+ Network Security
+
+ Transactions between the client and RADIUS accounting server
+ are authenticated through the use of a shared secret, which is
+ never sent over the network.
+
+ Extensible Protocol
+
+ All transactions are comprised of variable length Attribute-
+ Length-Value 3-tuples. New attribute values can be added
+ without disturbing existing implementations of the protocol.
+
+1.1. Specification of Requirements
+
+ 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 [3]. These
+ key words mean the same thing whether capitalized or not.
+
+1.2. Terminology
+
+ This document uses the following terms:
+
+ service The NAS provides a service to the dial-in user, such as PPP
+ or Telnet.
+
+ session Each service provided by the NAS to a dial-in user
+ constitutes a session, with the beginning of the session
+ defined as the point where service is first provided and
+ the end of the session defined as the point where service
+ is ended. A user may have multiple sessions in parallel or
+ series if the NAS supports that, with each session
+ generating a separate start and stop accounting record with
+ its own Acct-Session-Id.
+
+ 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.
+
+
+
+Rigney Informational [Page 3]
+
+RFC 2866 RADIUS Accounting June 2000
+
+
+2. Operation
+
+ When a client is configured to use RADIUS Accounting, at the start of
+ service delivery it will generate an Accounting Start packet
+ describing the type of service being delivered and the user it is
+ being delivered to, and will send that to the RADIUS Accounting
+ server, which will send back an acknowledgement that the packet has
+ been received. At the end of service delivery the client will
+ generate an Accounting Stop packet describing the type of service
+ that was delivered and optionally statistics such as elapsed time,
+ input and output octets, or input and output packets. It will send
+ that to the RADIUS Accounting server, which will send back an
+ acknowledgement that the packet has been received.
+
+ The Accounting-Request (whether for Start or Stop) is submitted to
+ the RADIUS accounting server via the network. It is recommended that
+ the client continue attempting to send the Accounting-Request packet
+ until it receives an acknowledgement, using some form of backoff. If
+ no response is returned within a length of time, the request is re-
+ sent a number of times. The client can also forward requests to an
+ alternate server or servers in the event that the primary server is
+ down or unreachable. An alternate server can be used either after a
+ number of tries to the primary server fail, or in a round-robin
+ fashion. Retry and fallback algorithms are the topic of current
+ research and are not specified in detail in this document.
+
+ The RADIUS accounting server MAY make requests of other servers in
+ order to satisfy the request, in which case it acts as a client.
+
+ If the RADIUS accounting server is unable to successfully record the
+ accounting packet it MUST NOT send an Accounting-Response
+ acknowledgment to the client.
+
+2.1. Proxy
+
+ See the "RADIUS" RFC [2] for information on Proxy RADIUS. Proxy
+ Accounting RADIUS works the same way, as illustrated by the following
+ example.
+
+ 1. The NAS sends an accounting-request to the forwarding server.
+
+ 2. The forwarding server logs the accounting-request (if desired),
+ adds its Proxy-State (if desired) after any other Proxy-State
+ attributes, updates the Request Authenticator, and forwards the
+ request to the remote server.
+
+
+
+
+
+
+Rigney Informational [Page 4]
+
+RFC 2866 RADIUS Accounting June 2000
+
+
+ 3. The remote server logs the accounting-request (if desired),
+ copies all Proxy-State attributes in order and unmodified from
+ the request to the response packet, and sends the accounting-
+ response to the forwarding server.
+
+ 4. The forwarding server strips the last Proxy-State (if it added
+ one in step 2), updates the Response Authenticator and sends
+ the accounting-response to the NAS.
+
+ A forwarding server MUST not modify existing Proxy-State or Class
+ attributes present in the packet.
+
+ A forwarding server may either perform its forwarding function in a
+ pass through manner, where it sends retransmissions on as soon as it
+ gets them, or it may take responsibility for retransmissions, for
+ example in cases where the network link between forwarding and remote
+ server has very different characteristics than the link between NAS
+ and forwarding server.
+
+ Extreme care should be used when implementing a proxy server that
+ takes responsibility for retransmissions so that its retransmission
+ policy is robust and scalable.
+
+3. Packet Format
+
+ Exactly one RADIUS Accounting packet is encapsulated in the UDP Data
+ field [4], where the UDP Destination Port field indicates 1813
+ (decimal).
+
+ When a reply is generated, the source and destination ports are
+ reversed.
+
+ This memo documents the RADIUS Accounting protocol. The early
+ deployment of RADIUS Accounting was done using UDP port number 1646,
+ which conflicts with the "sa-msg-port" service. The officially
+ assigned port number for RADIUS Accounting is 1813.
+
+ A summary of the RADIUS data format is shown below. The fields are
+ transmitted from left to right.
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney Informational [Page 5]
+
+RFC 2866 RADIUS Accounting June 2000
+
+
+ 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ | Authenticator |
+ | |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Attributes ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-
+
+
+ Code
+
+ The Code field is one octet, and identifies the type of RADIUS
+ packet. When a packet is received with an invalid Code field, it
+ is silently discarded.
+
+ RADIUS Accounting Codes (decimal) are assigned as follows:
+
+ 4 Accounting-Request
+ 5 Accounting-Response
+
+ Identifier
+
+ The Identifier field is one octet, and aids in matching requests
+ and replies. The RADIUS server can detect a duplicate request if
+ it has the same client source IP address and source UDP port and
+ Identifier within a short span of time.
+
+ Length
+
+ The Length field is two octets. It indicates the length of the
+ packet including the Code, Identifier, Length, Authenticator and
+ Attribute fields. Octets outside the range of the Length field
+ MUST be treated as padding and ignored on reception. If the
+ packet is shorter than the Length field indicates, it MUST be
+ silently discarded. The minimum length is 20 and maximum length
+ is 4095.
+
+ Authenticator
+
+ The Authenticator field is sixteen (16) octets. The most
+ significant octet is transmitted first. This value is used to
+ authenticate the messages between the client and RADIUS accounting
+ server.
+
+
+
+Rigney Informational [Page 6]
+
+RFC 2866 RADIUS Accounting June 2000
+
+
+ Request Authenticator
+
+ In Accounting-Request Packets, the Authenticator value is a 16
+ octet MD5 [5] checksum, called the Request Authenticator.
+
+ The NAS and RADIUS accounting server share a secret. The Request
+ Authenticator field in Accounting-Request packets contains a one-
+ way MD5 hash calculated over a stream of octets consisting of the
+ Code + Identifier + Length + 16 zero octets + request attributes +
+ shared secret (where + indicates concatenation). The 16 octet MD5
+ hash value is stored in the Authenticator field of the
+ Accounting-Request packet.
+
+ Note that the Request Authenticator of an Accounting-Request can
+ not be done the same way as the Request Authenticator of a RADIUS
+ Access-Request, because there is no User-Password attribute in an
+ Accounting-Request.
+
+ Response Authenticator
+
+ The Authenticator field in an Accounting-Response packet is called
+ the Response Authenticator, and contains a one-way MD5 hash
+ calculated over a stream of octets consisting of the Accounting-
+ Response Code, Identifier, Length, the Request Authenticator field
+ from the Accounting-Request packet being replied to, and the
+ response attributes if any, followed by the shared secret. The
+ resulting 16 octet MD5 hash value is stored in the Authenticator
+ field of the Accounting-Response packet.
+
+ Attributes
+
+ Attributes may have multiple instances, in such a case the order
+ of attributes of the same type SHOULD be preserved. The order of
+ attributes of different types is not required to be preserved.
+
+4. Packet Types
+
+ The RADIUS packet type is determined by the Code field in the first
+ octet of the packet.
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney Informational [Page 7]
+
+RFC 2866 RADIUS Accounting June 2000
+
+
+4.1. Accounting-Request
+
+ Description
+
+ Accounting-Request packets are sent from a client (typically a
+ Network Access Server or its proxy) to a RADIUS accounting server,
+ and convey information used to provide accounting for a service
+ provided to a user. The client transmits a RADIUS packet with the
+ Code field set to 4 (Accounting-Request).
+
+ Upon receipt of an Accounting-Request, the server MUST transmit an
+ Accounting-Response reply if it successfully records the
+ accounting packet, and MUST NOT transmit any reply if it fails to
+ record the accounting packet.
+
+ Any attribute valid in a RADIUS Access-Request or Access-Accept
+ packet is valid in a RADIUS Accounting-Request packet, except that
+ the following attributes MUST NOT be present in an Accounting-
+ Request: User-Password, CHAP-Password, Reply-Message, State.
+ Either NAS-IP-Address or NAS-Identifier MUST be present in a
+ RADIUS Accounting-Request. It SHOULD contain a NAS-Port or NAS-
+ Port-Type attribute or both unless the service does not involve a
+ port or the NAS does not distinguish among its ports.
+
+ If the Accounting-Request packet includes a Framed-IP-Address,
+ that attribute MUST contain the IP address of the user. If the
+ Access-Accept used the special values for Framed-IP-Address
+ telling the NAS to assign or negotiate an IP address for the user,
+ the Framed-IP-Address (if any) in the Accounting-Request MUST
+ contain the actual IP address assigned or negotiated.
+
+ A summary of the Accounting-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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ | Request Authenticator |
+ | |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Attributes ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-
+
+
+
+
+Rigney Informational [Page 8]
+
+RFC 2866 RADIUS Accounting June 2000
+
+
+ Code
+
+ 4 for Accounting-Request.
+
+ Identifier
+
+ The Identifier field MUST be changed whenever the content of the
+ Attributes field changes, and whenever a valid reply has been
+ received for a previous request. For retransmissions where the
+ contents are identical, the Identifier MUST remain unchanged.
+
+ Note that if Acct-Delay-Time is included in the attributes of an
+ Accounting-Request then the Acct-Delay-Time value will be updated
+ when the packet is retransmitted, changing the content of the
+ Attributes field and requiring a new Identifier and Request
+ Authenticator.
+
+ Request Authenticator
+
+ The Request Authenticator of an Accounting-Request contains a 16-octet
+ MD5 hash value calculated according to the method described in
+ "Request Authenticator" above.
+
+ Attributes
+
+ The Attributes field is variable in length, and contains a list of
+ Attributes.
+
+4.2. Accounting-Response
+
+ Description
+
+ Accounting-Response packets are sent by the RADIUS accounting
+ server to the client to acknowledge that the Accounting-Request
+ has been received and recorded successfully. If the Accounting-
+ Request was recorded successfully then the RADIUS accounting
+ server MUST transmit a packet with the Code field set to 5
+ (Accounting-Response). On reception of an Accounting-Response by
+ the client, the Identifier field is matched with a pending
+ Accounting-Request. The Response Authenticator field MUST contain
+ the correct response for the pending Accounting-Request. Invalid
+ packets are silently discarded.
+
+ A RADIUS Accounting-Response is not required to have any
+ attributes in it.
+
+ A summary of the Accounting-Response packet format is shown below.
+ The fields are transmitted from left to right.
+
+
+
+Rigney Informational [Page 9]
+
+RFC 2866 RADIUS Accounting June 2000
+
+
+ 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ | Response Authenticator |
+ | |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Attributes ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Code
+
+ 5 for Accounting-Response.
+
+ Identifier
+
+ The Identifier field is a copy of the Identifier field of the
+ Accounting-Request which caused this Accounting-Response.
+
+ Response Authenticator
+
+ The Response Authenticator of an Accounting-Response contains a
+ 16-octet MD5 hash value calculated according to the method
+ described in "Response Authenticator" above.
+
+ Attributes
+
+ The Attributes field is variable in length, and contains a list of
+ zero or more Attributes.
+
+5. Attributes
+
+ RADIUS Attributes carry the specific authentication, authorization
+ and accounting details for the request and response.
+
+ Some attributes MAY be included more than once. The effect of this
+ is attribute specific, and is specified in each attribute
+ description.
+
+ The end of the list of attributes is indicated by the Length of the
+ RADIUS packet.
+
+ A summary of the attribute format is shown below. The fields are
+ transmitted from left to right.
+
+
+
+
+Rigney Informational [Page 10]
+
+RFC 2866 RADIUS Accounting June 2000
+
+
+ 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 | Value ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ Type
+
+ The Type field is one octet. Up-to-date values of the RADIUS Type
+ field are specified in the most recent "Assigned Numbers" RFC [6].
+ Values 192-223 are reserved for experimental use, values 224-240
+ are reserved for implementation-specific use, and values 241-255
+ are reserved and should not be used. This specification concerns
+ the following values:
+
+ 1-39 (refer to RADIUS document [2])
+ 40 Acct-Status-Type
+ 41 Acct-Delay-Time
+ 42 Acct-Input-Octets
+ 43 Acct-Output-Octets
+ 44 Acct-Session-Id
+ 45 Acct-Authentic
+ 46 Acct-Session-Time
+ 47 Acct-Input-Packets
+ 48 Acct-Output-Packets
+ 49 Acct-Terminate-Cause
+ 50 Acct-Multi-Session-Id
+ 51 Acct-Link-Count
+ 60+ (refer to RADIUS document [2])
+
+ Length
+
+ The Length field is one octet, and indicates the length of this
+ attribute including the Type, Length and Value fields. If an
+ attribute is received in an Accounting-Request with an invalid
+ Length, the entire request MUST be silently discarded.
+
+ Value
+
+ The Value field is zero or more octets and contains information
+ specific to the attribute. The format and length of the Value
+ field is determined by the Type and Length fields.
+
+ Note that none of the types in RADIUS terminate with a NUL (hex
+ 00). In particular, types "text" and "string" in RADIUS do not
+ terminate with a NUL (hex 00). The Attribute has a length field
+ and does not use a terminator. Text contains UTF-8 encoded 10646
+
+
+
+Rigney Informational [Page 11]
+
+RFC 2866 RADIUS Accounting June 2000
+
+
+ [7] characters and String contains 8-bit binary data. Servers and
+ servers and clients MUST be able to deal with embedded nulls.
+ RADIUS implementers using C are cautioned not to use strcpy() when
+ handling strings.
+
+ The format of the value field is one of five data types. Note
+ that type "text" is a subset of type "string."
+
+ text 1-253 octets containing UTF-8 encoded 10646 [7]
+ characters. Text of length zero (0) MUST NOT be sent;
+ omit the entire attribute instead.
+
+ string 1-253 octets containing binary data (values 0 through 255
+ decimal, inclusive). Strings of length zero (0) MUST NOT
+ be sent; omit the entire attribute instead.
+
+ address 32 bit value, most significant octet first.
+
+ integer 32 bit unsigned value, most significant octet first.
+
+ time 32 bit unsigned value, most significant octet first --
+ seconds since 00:00:00 UTC, January 1, 1970. The
+ standard Attributes do not use this data type but it is
+ presented here for possible use in future attributes.
+
+5.1. Acct-Status-Type
+
+ Description
+
+ This attribute indicates whether this Accounting-Request marks the
+ beginning of the user service (Start) or the end (Stop).
+
+ It MAY be used by the client to mark the start of accounting (for
+ example, upon booting) by specifying Accounting-On and to mark the
+ end of accounting (for example, just before a scheduled reboot) by
+ specifying Accounting-Off.
+
+ A summary of the Acct-Status-Type attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+Rigney Informational [Page 12]
+
+RFC 2866 RADIUS Accounting June 2000
+
+
+ Type
+
+ 40 for Acct-Status-Type.
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets.
+
+ 1 Start
+ 2 Stop
+ 3 Interim-Update
+ 7 Accounting-On
+ 8 Accounting-Off
+ 9-14 Reserved for Tunnel Accounting
+ 15 Reserved for Failed
+
+5.2. Acct-Delay-Time
+
+ Description
+
+ This attribute indicates how many seconds the client has been
+ trying to send this record for, and can be subtracted from the
+ time of arrival on the server to find the approximate time of the
+ event generating this Accounting-Request. (Network transit time
+ is ignored.)
+
+ Note that changing the Acct-Delay-Time causes the Identifier to
+ change; see the discussion under Identifier above.
+
+ A summary of the Acct-Delay-Time attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+Rigney Informational [Page 13]
+
+RFC 2866 RADIUS Accounting June 2000
+
+
+ Type
+
+ 41 for Acct-Delay-Time.
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets.
+
+5.3. Acct-Input-Octets
+
+ Description
+
+ This attribute indicates how many octets have been received from
+ the port over the course of this service being provided, and can
+ only be present in Accounting-Request records where the Acct-
+ Status-Type is set to Stop.
+
+ A summary of the Acct-Input-Octets attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 42 for Acct-Input-Octets.
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets.
+
+
+
+
+
+
+
+
+Rigney Informational [Page 14]
+
+RFC 2866 RADIUS Accounting June 2000
+
+
+5.4. Acct-Output-Octets
+
+ Description
+
+ This attribute indicates how many octets have been sent to the
+ port in the course of delivering this service, and can only be
+ present in Accounting-Request records where the Acct-Status-Type
+ is set to Stop.
+
+ A summary of the Acct-Output-Octets attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 43 for Acct-Output-Octets.
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets.
+
+5.5. Acct-Session-Id
+
+ Description
+
+ This attribute is a unique Accounting ID to make it easy to match
+ start and stop records in a log file. The start and stop records
+ for a given session MUST have the same Acct-Session-Id. An
+ Accounting-Request packet MUST have an Acct-Session-Id. An
+ Access-Request packet MAY have an Acct-Session-Id; if it does,
+ then the NAS MUST use the same Acct-Session-Id in the Accounting-
+ Request packets for that session.
+
+ The Acct-Session-Id SHOULD contain UTF-8 encoded 10646 [7]
+ characters.
+
+
+
+
+
+Rigney Informational [Page 15]
+
+RFC 2866 RADIUS Accounting June 2000
+
+
+ For example, one implementation uses a string with an 8-digit
+ upper case hexadecimal number, the first two digits increment on
+ each reboot (wrapping every 256 reboots) and the next 6 digits
+ counting from 0 for the first person logging in after a reboot up
+ to 2^24-1, about 16 million. Other encodings are possible.
+
+ A summary of the Acct-Session-Id attribute 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 | Text ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 44 for Acct-Session-Id.
+
+ Length
+
+ >= 3
+
+ String
+
+ The String field SHOULD be a string of UTF-8 encoded 10646 [7]
+ characters.
+
+5.6. Acct-Authentic
+
+ Description
+
+ This attribute MAY be included in an Accounting-Request to
+ indicate how the user was authenticated, whether by RADIUS, the
+ NAS itself, or another remote authentication protocol. Users who
+ are delivered service without being authenticated SHOULD NOT
+ generate Accounting records.
+
+ A summary of the Acct-Authentic attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+Rigney Informational [Page 16]
+
+RFC 2866 RADIUS Accounting June 2000
+
+
+ Type
+
+ 45 for Acct-Authentic.
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets.
+
+ 1 RADIUS
+ 2 Local
+ 3 Remote
+
+5.7. Acct-Session-Time
+
+ Description
+
+ This attribute indicates how many seconds the user has received
+ service for, and can only be present in Accounting-Request records
+ where the Acct-Status-Type is set to Stop.
+
+ A summary of the Acct-Session-Time attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 46 for Acct-Session-Time.
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets.
+
+
+
+
+
+Rigney Informational [Page 17]
+
+RFC 2866 RADIUS Accounting June 2000
+
+
+5.8. Acct-Input-Packets
+
+ Description
+
+ This attribute indicates how many packets have been received from
+ the port over the course of this service being provided to a
+ Framed User, and can only be present in Accounting-Request records
+ where the Acct-Status-Type is set to Stop.
+
+ A summary of the Acct-Input-packets attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 47 for Acct-Input-Packets.
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets.
+
+5.9. Acct-Output-Packets
+
+ Description
+
+ This attribute indicates how many packets have been sent to the
+ port in the course of delivering this service to a Framed User,
+ and can only be present in Accounting-Request records where the
+ Acct-Status-Type is set to Stop.
+
+ A summary of the Acct-Output-Packets attribute format is shown below.
+ The fields are transmitted from left to right.
+
+
+
+
+
+
+
+
+Rigney Informational [Page 18]
+
+RFC 2866 RADIUS Accounting June 2000
+
+
+ 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 48 for Acct-Output-Packets.
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets.
+
+5.10. Acct-Terminate-Cause
+
+ Description
+
+ This attribute indicates how the session was terminated, and can
+ only be present in Accounting-Request records where the Acct-
+ Status-Type is set to Stop.
+
+ A summary of the Acct-Terminate-Cause attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney Informational [Page 19]
+
+RFC 2866 RADIUS Accounting June 2000
+
+
+ Type
+
+ 49 for Acct-Terminate-Cause
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets, containing an integer specifying
+ the cause of session termination, as follows:
+
+ 1 User Request
+ 2 Lost Carrier
+ 3 Lost Service
+ 4 Idle Timeout
+ 5 Session Timeout
+ 6 Admin Reset
+ 7 Admin Reboot
+ 8 Port Error
+ 9 NAS Error
+ 10 NAS Request
+ 11 NAS Reboot
+ 12 Port Unneeded
+ 13 Port Preempted
+ 14 Port Suspended
+ 15 Service Unavailable
+ 16 Callback
+ 17 User Error
+ 18 Host Request
+
+ The termination causes are as follows:
+
+ User Request User requested termination of service, for
+ example with LCP Terminate or by logging out.
+
+ Lost Carrier DCD was dropped on the port.
+
+ Lost Service Service can no longer be provided; for
+ example, user's connection to a host was
+ interrupted.
+
+ Idle Timeout Idle timer expired.
+
+ Session Timeout Maximum session length timer expired.
+
+ Admin Reset Administrator reset the port or session.
+
+
+
+Rigney Informational [Page 20]
+
+RFC 2866 RADIUS Accounting June 2000
+
+
+ Admin Reboot Administrator is ending service on the NAS,
+ for example prior to rebooting the NAS.
+
+ Port Error NAS detected an error on the port which
+ required ending the session.
+
+ NAS Error NAS detected some error (other than on the
+ port) which required ending the session.
+
+ NAS Request NAS ended session for a non-error reason not
+ otherwise listed here.
+
+ NAS Reboot The NAS ended the session in order to reboot
+ non-administratively ("crash").
+
+ Port Unneeded NAS ended session because resource usage fell
+ below low-water mark (for example, if a
+ bandwidth-on-demand algorithm decided that
+ the port was no longer needed).
+
+ Port Preempted NAS ended session in order to allocate the
+ port to a higher priority use.
+
+ Port Suspended NAS ended session to suspend a virtual
+ session.
+
+ Service Unavailable NAS was unable to provide requested service.
+
+ Callback NAS is terminating current session in order
+ to perform callback for a new session.
+
+ User Error Input from user is in error, causing
+ termination of session.
+
+ Host Request Login Host terminated session normally.
+
+5.11. Acct-Multi-Session-Id
+
+ Description
+
+ This attribute is a unique Accounting ID to make it easy to link
+ together multiple related sessions in a log file. Each session
+ linked together would have a unique Acct-Session-Id but the same
+ Acct-Multi-Session-Id. It is strongly recommended that the Acct-
+ Multi-Session-Id contain UTF-8 encoded 10646 [7] characters.
+
+ A summary of the Acct-Session-Id attribute format is shown below.
+ The fields are transmitted from left to right.
+
+
+
+Rigney Informational [Page 21]
+
+RFC 2866 RADIUS Accounting June 2000
+
+
+ 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 | String ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 50 for Acct-Multi-Session-Id.
+
+ Length
+
+ >= 3
+
+ String
+
+ The String field SHOULD contain UTF-8 encoded 10646 [7] characters.
+
+5.12. Acct-Link-Count
+
+ Description
+
+ This attribute gives the count of links which are known to have been
+ in a given multilink session at the time the accounting record is
+ generated. The NAS MAY include the Acct-Link-Count attribute in any
+ Accounting-Request which might have multiple links.
+
+ A summary of the Acct-Link-Count attribute format is show 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney Informational [Page 22]
+
+RFC 2866 RADIUS Accounting June 2000
+
+
+ Type
+
+ 51 for Acct-Link-Count.
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets, and contains the number of links
+ seen so far in this Multilink Session.
+
+ It may be used to make it easier for an accounting server to know
+ when it has all the records for a given Multilink session. When
+ the number of Accounting-Requests received with Acct-Status-Type =
+ Stop and the same Acct-Multi-Session-Id and unique Acct-Session-
+ Id's equals the largest value of Acct-Link-Count seen in those
+ Accounting-Requests, all Stop Accounting-Requests for that
+ Multilink Session have been received.
+
+ An example showing 8 Accounting-Requests should make things
+ clearer. For clarity only the relevant attributes are shown, but
+ additional attributes containing accounting information will also
+ be present in the Accounting-Request.
+
+ Multi-Session-Id Session-Id Status-Type Link-Count
+ "10" "10" Start 1
+ "10" "11" Start 2
+ "10" "11" Stop 2
+ "10" "12" Start 3
+ "10" "13" Start 4
+ "10" "12" Stop 4
+ "10" "13" Stop 4
+ "10" "10" Stop 4
+
+5.13. Table of Attributes
+
+ The following table provides a guide to which attributes may be found
+ in Accounting-Request packets. No attributes should be found in
+ Accounting-Response packets except Proxy-State and possibly Vendor-
+ Specific.
+
+
+ # Attribute
+ 0-1 User-Name
+ 0 User-Password
+ 0 CHAP-Password
+
+
+
+Rigney Informational [Page 23]
+
+RFC 2866 RADIUS Accounting June 2000
+
+
+ 0-1 NAS-IP-Address [Note 1]
+ 0-1 NAS-Port
+ 0-1 Service-Type
+ 0-1 Framed-Protocol
+ 0-1 Framed-IP-Address
+ 0-1 Framed-IP-Netmask
+ 0-1 Framed-Routing
+ 0+ Filter-Id
+ 0-1 Framed-MTU
+ 0+ Framed-Compression
+ 0+ Login-IP-Host
+ 0-1 Login-Service
+ 0-1 Login-TCP-Port
+ 0 Reply-Message
+ 0-1 Callback-Number
+ 0-1 Callback-Id
+ 0+ Framed-Route
+ 0-1 Framed-IPX-Network
+ 0 State
+ 0+ Class
+ 0+ Vendor-Specific
+ 0-1 Session-Timeout
+ 0-1 Idle-Timeout
+ 0-1 Termination-Action
+ 0-1 Called-Station-Id
+ 0-1 Calling-Station-Id
+ 0-1 NAS-Identifier [Note 1]
+ 0+ Proxy-State
+ 0-1 Login-LAT-Service
+ 0-1 Login-LAT-Node
+ 0-1 Login-LAT-Group
+ 0-1 Framed-AppleTalk-Link
+ 0-1 Framed-AppleTalk-Network
+ 0-1 Framed-AppleTalk-Zone
+ 1 Acct-Status-Type
+ 0-1 Acct-Delay-Time
+ 0-1 Acct-Input-Octets
+ 0-1 Acct-Output-Octets
+ 1 Acct-Session-Id
+ 0-1 Acct-Authentic
+ 0-1 Acct-Session-Time
+ 0-1 Acct-Input-Packets
+ 0-1 Acct-Output-Packets
+ 0-1 Acct-Terminate-Cause
+ 0+ Acct-Multi-Session-Id
+ 0+ Acct-Link-Count
+ 0 CHAP-Challenge
+
+
+
+
+Rigney Informational [Page 24]
+
+RFC 2866 RADIUS Accounting June 2000
+
+
+ 0-1 NAS-Port-Type
+ 0-1 Port-Limit
+ 0-1 Login-LAT-Port
+
+ [Note 1] An Accounting-Request MUST contain either a NAS-IP-Address
+ or a NAS-Identifier (or both).
+
+ The following table defines the above table entries.
+
+ 0 This attribute MUST NOT be present
+ 0+ Zero or more instances of this attribute MAY be present.
+ 0-1 Zero or one instance of this attribute MAY be present.
+ 1 Exactly one instance of this attribute MUST be present.
+
+6. IANA Considerations
+
+ The Packet Type Codes, Attribute Types, and Attribute Values defined
+ in this document are registered by the Internet Assigned Numbers
+ Authority (IANA) from the RADIUS name spaces as described in the
+ "IANA Considerations" section of RFC 2865 [2], in accordance with BCP
+ 26 [8].
+
+7. Security Considerations
+
+ Security issues are discussed in sections concerning the
+ authenticator included in accounting requests and responses, using a
+ shared secret which is never sent over the network.
+
+8. Change Log
+
+ US-ASCII replaced by UTF-8.
+
+ Added notes on Proxy.
+
+ Framed-IP-Address should contain the actual IP address of the user.
+
+ If Acct-Session-ID was sent in an access-request, it must be used in
+ the accounting-request for that session.
+
+ New values added to Acct-Status-Type.
+
+ Added an IANA Considerations section.
+
+ Updated references.
+
+ Text strings identified as a subset of string, to clarify use of
+ UTF-8.
+
+
+
+
+Rigney Informational [Page 25]
+
+RFC 2866 RADIUS Accounting June 2000
+
+
+9. References
+
+ [1] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
+
+ [2] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
+ Authentication Dial In User Service (RADIUS)", RFC 2865, June
+ 2000.
+
+ [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March, 1997.
+
+ [4] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
+ 1980.
+
+ [5] Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", RFC
+ 1321, April 1992.
+
+ [6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
+ October 1994.
+
+ [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
+ 2279, January 1998.
+
+ [8] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
+ Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+10. Acknowledgements
+
+ RADIUS and RADIUS Accounting were originally developed by Steve
+ Willens of Livingston Enterprises for their PortMaster series of
+ Network Access Servers.
+
+11. Chair's Address
+
+ The RADIUS working group can be contacted via the current chair:
+
+ Carl Rigney
+ Livingston Enterprises
+ 4464 Willow Road
+ Pleasanton, California 94588
+
+ Phone: +1 925 737 2100
+ EMail: cdr@telemancy.com
+
+
+
+
+
+
+
+
+Rigney Informational [Page 26]
+
+RFC 2866 RADIUS Accounting June 2000
+
+
+12. Author's Address
+
+ Questions about this memo can also be directed to:
+
+ Carl Rigney
+ Livingston Enterprises
+ 4464 Willow Road
+ Pleasanton, California 94588
+
+ EMail: cdr@telemancy.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney Informational [Page 27]
+
+RFC 2866 RADIUS Accounting June 2000
+
+
+13. 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney Informational [Page 28]
+
diff --git a/rfc/rfc2869.txt b/rfc/rfc2869.txt
new file mode 100644
index 0000000..74ed7f6
--- /dev/null
+++ b/rfc/rfc2869.txt
@@ -0,0 +1,2635 @@
+
+
+
+
+
+
+Network Working Group C. Rigney
+Request for Comments: 2869 Livingston
+Category: Informational W. Willats
+ Cyno Technologies
+ P. Calhoun
+ Sun Microsystems
+ June 2000
+
+
+ RADIUS 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 (2000). All Rights Reserved.
+
+Abstract
+
+ This document describes additional attributes for carrying
+ authentication, authorization and accounting information between a
+ Network Access Server (NAS) and a shared Accounting Server using the
+ Remote Authentication Dial In User Service (RADIUS) protocol
+ described in RFC 2865 [1] and RFC 2866 [2].
+
+Table of Contents
+
+ 1. Introduction .......................................... 2
+ 1.1 Specification of Requirements ................... 3
+ 1.2 Terminology ..................................... 3
+ 2. Operation ............................................. 4
+ 2.1 RADIUS support for Interim Accounting Updates.... 4
+ 2.2 RADIUS support for Apple Remote Access
+ Protocol ........................................ 5
+ 2.3 RADIUS Support for Extensible Authentication
+ Protocol (EAP) .................................. 11
+ 2.3.1 Protocol Overview ............................... 11
+ 2.3.2 Retransmission .................................. 13
+ 2.3.3 Fragmentation ................................... 14
+ 2.3.4 Examples ........................................ 14
+ 2.3.5 Alternative uses ................................ 19
+ 3. Packet Format ......................................... 19
+ 4. Packet Types .......................................... 19
+ 5. Attributes ............................................ 20
+
+
+
+Rigney, et al. Informational [Page 1]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+ 5.1 Acct-Input-Gigawords ............................ 22
+ 5.2 Acct-Output-Gigawords ........................... 23
+ 5.3 Event-Timestamp ................................. 23
+ 5.4 ARAP-Password ................................... 24
+ 5.5 ARAP-Features ................................... 25
+ 5.6 ARAP-Zone-Access ................................ 26
+ 5.7 ARAP-Security ................................... 27
+ 5.8 ARAP-Security-Data .............................. 28
+ 5.9 Password-Retry .................................. 28
+ 5.10 Prompt .......................................... 29
+ 5.11 Connect-Info .................................... 30
+ 5.12 Configuration-Token ............................. 31
+ 5.13 EAP-Message ..................................... 32
+ 5.14 Message-Authenticator ........................... 33
+ 5.15 ARAP-Challenge-Response ......................... 35
+ 5.16 Acct-Interim-Interval ........................... 36
+ 5.17 NAS-Port-Id ..................................... 37
+ 5.18 Framed-Pool ..................................... 37
+ 5.19 Table of Attributes ............................. 38
+ 6. IANA Considerations ................................... 39
+ 7. Security Considerations ............................... 39
+ 7.1 Message-Authenticator Security .................. 39
+ 7.2 EAP Security .................................... 39
+ 7.2.1 Separation of EAP server and PPP authenticator .. 40
+ 7.2.2 Connection hijacking ............................ 41
+ 7.2.3 Man in the middle attacks ....................... 41
+ 7.2.4 Multiple databases .............................. 41
+ 7.2.5 Negotiation attacks ............................. 42
+ 8. References ............................................ 43
+ 9. Acknowledgements ...................................... 44
+ 10. Chair's Address ....................................... 44
+ 11. Authors' Addresses .................................... 45
+ 12. Full Copyright Statement .............................. 47
+
+1. Introduction
+
+ RFC 2865 [1] describes the RADIUS Protocol as it is implemented and
+ deployed today, and RFC 2866 [2] describes how Accounting can be
+ performed with RADIUS.
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et al. Informational [Page 2]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+ This memo suggests several additional Attributes that can be added to
+ RADIUS to perform various useful functions. These Attributes do not
+ have extensive field experience yet and should therefore be
+ considered experimental.
+
+ The Extensible Authentication Protocol (EAP) [3] is a PPP extension
+ that provides support for additional authentication methods within
+ PPP. This memo describes how the EAP-Message and Message-
+ Authenticator attributes may be used for providing EAP support within
+ RADIUS.
+
+ All attributes are comprised of variable length Type-Length-Value 3-
+ tuples. New attribute values can be added without disturbing
+ existing implementations of the protocol.
+
+1.1. Specification of Requirements
+
+ 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 [4].
+
+ An implementation is not compliant if it fails to satisfy one or more
+ of the must or must not requirements for the protocols it implements.
+ An implementation that satisfies all the must, must not, should and
+ should not requirements for its protocols is said to be
+ "unconditionally compliant"; one that satisfies all the must and must
+ not requirements but not all the should or should not requirements
+ for its protocols is said to be "conditionally compliant."
+
+ A NAS that does not implement a given service MUST NOT implement the
+ RADIUS attributes for that service. For example, a NAS that is
+ unable to offer ARAP service MUST NOT implement the RADIUS attributes
+ for ARAP. A NAS MUST treat a RADIUS access-request requesting an
+ unavailable service as an access-reject instead.
+
+1.2. Terminology
+
+ This document uses the following terms:
+
+ service The NAS provides a service to the dial-in user, such as PPP
+ or Telnet.
+
+ session Each service provided by the NAS to a dial-in user
+ constitutes a session, with the beginning of the session
+ defined as the point where service is first provided and
+ the end of the session defined as the point where service
+
+
+
+
+
+Rigney, et al. Informational [Page 3]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+ is ended. A user may have multiple sessions in parallel or
+ series if the NAS supports that, with each session
+ generating a separate start and stop accounting record.
+
+ 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. Operation
+
+ Operation is identical to that defined in RFC 2865 [1] and RFC 2866
+ [2].
+
+2.1. RADIUS support for Interim Accounting Updates
+
+ When a user is authenticated, a RADIUS server issues an Access-Accept
+ in response to a successful Access-Request. If the server wishes to
+ receive interim accounting messages for the given user it must
+ include the Acct-Interim-Interval RADIUS attribute in the message,
+ which indicates the interval in seconds between interim messages.
+
+ It is also possible to statically configure an interim value on the
+ NAS itself. Note that a locally configured value on the NAS MUST
+ override the value found in an Access-Accept.
+
+ This scheme does not break backward interoperability since a RADIUS
+ server not supporting this extension will simply not add the new
+ Attribute. NASes not supporting this extension will ignore the
+ Attribute.
+
+ Note that all information in an interim message is cumulative (i.e.
+ number of packets sent is the total since the beginning of the
+ session, not since the last interim message).
+
+ It is envisioned that an Interim Accounting record (with Acct-
+ Status-Type = Interim-Update (3)) would contain all of the attributes
+ normally found in an Accounting Stop message with the exception of
+ the Acct-Term-Cause attribute.
+
+ Since all the information is cumulative, a NAS MUST ensure that only
+ a single generation of an interim Accounting message for a given
+ session is present in the retransmission queue at any given time.
+
+
+
+
+
+
+Rigney, et al. Informational [Page 4]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+ A NAS MAY use a fudge factor to add a random delay between Interim
+ Accounting messages for separate sessions. This will ensure that a
+ cycle where all messages are sent at once is prevented, such as might
+ otherwise occur if a primary link was recently restored and many
+ dial-up users were directed to the same NAS at once.
+
+ The Network and NAS CPU load of using Interim Updates should be
+ carefully considered, and appropriate values of Acct-Interim-Interval
+ chosen.
+
+2.2. RADIUS support for Apple Remote Access Protocol
+
+ The RADIUS (Remote Authentication Dial-In User Service) protocol
+ provides a method that allows multiple dial-in Network Access Server
+ (NAS) devices to share a common authentication database.
+
+ The Apple Remote Access Protocol (ARAP) provides a method for sending
+ AppleTalk network traffic over point-to-point links, typically, but
+ not exclusively, asynchronous and ISDN switched-circuit connections.
+ Though Apple is moving toward ATCP on PPP for future remote access
+ services, ARAP is still a common way for the installed base of
+ Macintosh users to make remote network connections, and is likely to
+ remain so for some time.
+
+ ARAP is supported by several NAS vendors who also support PPP, IPX
+ and other protocols in the same NAS. ARAP connections in these
+ multi-protocol devices are often not authenticated with RADIUS, or if
+ they are, each vendor creates an individual solution to the problem.
+
+ This section describes the use of additional RADIUS attributes to
+ support ARAP. RADIUS client and server implementations that implement
+ this specification should be able to authenticate ARAP connections in
+ an interoperable manner.
+
+ This section assumes prior knowledge of RADIUS, and will go into some
+ detail on the operation of ARAP before entering a detailed discussion
+ of the proposed ARAP RADIUS attributes.
+
+ There are two features of ARAP this document does not address:
+
+ 1. User initiated password changing. This is not part of RADIUS,
+ but can be implemented through a software process other than
+ RADIUS.
+
+ 2. Out-of-Band messages. At any time, the NAS can send messages to
+ an ARA client which appear in a dialog box on the dial-in
+ user's screen. These are not part of authentication and do not
+ belong here. However, we note that a Reply-Message attribute in
+
+
+
+Rigney, et al. Informational [Page 5]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+ an Access-Accept may be sent down to the user as a sign-on
+ message of the day string using the out-of-band channel.
+
+ We have tried to respect the spirit of the existing RADIUS protocol
+ as much as possible, making design decisions compatible with prior
+ art. Further, we have tried to strike a balance between flooding the
+ RADIUS world with new attributes, and hiding all of ARAP operation
+ within a single multiplexed ARAP attribute string or within Extended
+ Authentication Protocol (EAP) [3] machinery.
+
+ However, we feel ARAP is enough of a departure from PPP to warrant a
+ small set of similarly named attributes of its own.
+
+ We have assumed that an ARAP-aware RADIUS server will be able to do
+ DES encryption and generate security module challenges. This is in
+ keeping with the general RADIUS goal of smart server / simple NAS.
+
+ ARAP authenticates a connection in two phases. The first is a "Two-
+ Way DES" random number exchange, using the user's password as a key.
+ We say "Two-Way" because the ARAP NAS challenges the dial-in client
+ to authenticate itself, and the dial-in client challenges the ARAP
+ NAS to authenticate itself.
+
+ Specifically, ARAP does the following:
+
+ 1. The NAS sends two 32-bit random numbers to the dial-in client
+ in an ARAP msg_auth_challenge packet.
+
+ 2. The dial-in client uses the user's password to DES encrypt the
+ two random numbers sent to it by the NAS. The dial-in client
+ then sends this result, the user's name and two 32-bit random
+ numbers of its own back to the NAS in an ARAP msg_auth_request
+ packet.
+
+ 3. The NAS verifies the encrypted random numbers sent by the
+ dial-in client are what it expected. If so, it encrypts the
+ dial-in client's challenge using the password and sends it back
+ to the dial-in client in an ARAP msg_auth_response packet.
+
+ Note that if the dial-in client's response was wrong, meaning the
+ user has the wrong password, the server can initiate a retry sequence
+ up to the maximum amount of retries allowed by the NAS. In this case,
+ when the dial-in client receives the ARAP msg_auth_response packet it
+ will acknowledge it with an ARAP msg_auth_again packet.
+
+ After this first "DES Phase" the ARAP NAS MAY initiate a secondary
+ authentication phase using what Apple calls "Add-In Security
+ Modules." Security Modules are small pieces of code which run on
+
+
+
+Rigney, et al. Informational [Page 6]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+ both the client and server and are allowed to read and write
+ arbitrary data across the communications link to perform additional
+ authentication functions. Various security token vendors use this
+ mechanism to authenticate ARA callers.
+
+ Although ARAP allows security modules to read and write anything they
+ like, all existing security modules use simple challenge and response
+ cycles, with perhaps some overall control information. This document
+ assumes all existing security modules can be supported with one or
+ more challenge/response cycles.
+
+ To complicate RADIUS and ARAP integration, ARAP sends down some
+ profile information after the DES Phase and before the Security
+ Module phase. This means that besides the responses to challenges,
+ this profile information must also be present, at somewhat unusual
+ times. Fortunately the information is only a few pieces of numeric
+ data related to passwords, which this document packs into a single
+ new attribute.
+
+ Presenting an Access-Request to RADIUS on behalf of an ARAP
+ connection is straightforward. The ARAP NAS generates the random
+ number challenge, and then receives the dial-in client's response,
+ the dial-in client's challenge, and the user's name. Assuming the
+ user is not a guest, the following information is forwarded in an
+ Access-Request packet: User-Name (up to 31 characters long),
+ Framed-Protocol (set to 3, ARAP), ARAP-Password, and any additional
+ attributes desired, such as Service-Type, NAS-IP-Address, NAS-Id,
+ NAS-Port-Type, NAS-Port, NAS-Port-Id, Connect-Info, etc.
+
+ The Request Authenticator is a NAS-generated 16 octet random number.
+ The low-order 8 octets of this number are sent to the dial-in user as
+ the two 4 octet random numbers required in the ARAP
+ msg_auth_challenge packet. Octets 0-3 are the first random number and
+ Octets 4-7 are the second random number.
+
+ The ARAP-Password in the Access-Request contains a 16 octet random
+ number field, and is used to carry the dial-in user's response to the
+ NAS challenge and the client's own challenge to the NAS. The high-
+ order octets contain the dial-in user's challenge to the NAS (2 32-
+ bit numbers, 8 octets) and the low-order octets contain the dial-in
+ user's response to the NAS challenge (2 32-bit numbers, 8 octets).
+
+ Only one of User-Password, CHAP-Password, or ARAP-Password needs to
+ be present in an Access-Request, or one or more EAP-Messages.
+
+ If the RADIUS server does not support ARAP it SHOULD return an
+ Access-Reject to the NAS.
+
+
+
+
+Rigney, et al. Informational [Page 7]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+ If the RADIUS server does support ARAP, it should verify the user's
+ response using the Challenge (from the lower order 8 octets of the
+ Request Authenticator) and the user's response (from the low order 8
+ octets of the ARAP-Password).
+
+ If that authentication fails, the RADIUS server should return an
+ Access-Reject packet to the NAS, with optional Password-Retry and
+ Reply-Messages attributes. The presence of Password-Retry indicates
+ the ARAP NAS MAY choose to initiate another challenge-response cycle,
+ up to a total number of times equal to the integer value of the
+ Password-Retry attribute.
+
+ If the user is authenticated, the RADIUS server should return an
+ Access-Accept packet (Code 2) to the NAS, with ID and Response
+ Authenticator as usual, and attributes as follows:
+
+ Service-Type of Framed-Protocol.
+
+ Framed-Protocol of ARAP (3).
+
+ Session-Timeout with the maximum connect time for the user in
+ seconds. If the user is to be given unlimited time,
+ Session-Timeout should not be included in the Access-Accept
+ packet, and ARAP will treat that as an unlimited timeout (-1).
+
+ ARAP-Challenge-Response, containing 8 octets with the response to
+ the dial-in client's challenge. The RADIUS server calculates this
+ value by taking the dial-in client's challenge from the high order
+ 8 octets of the ARAP-Password attribute and performing DES
+ encryption on this value with the authenticating user's password
+ as the key. If the user's password is less than 8 octets in
+ length, the password is padded at the end with NULL octets to a
+ length of 8 before using it as a key. If the user's password is
+ greater than 8 octets in length, an Access-Reject MUST be sent
+ instead.
+
+ ARAP-Features, containing information that the NAS should send to
+ the user in an ARAP "feature flags" packet.
+
+ Octet 0: If zero, user cannot change their password. If non-
+ zero user can. (RADIUS does not handle the password changing,
+ just the attribute which indicates whether ARAP indicates they
+ can.)
+
+ Octet 1: Minimum acceptable password length (0-8).
+
+
+
+
+
+
+Rigney, et al. Informational [Page 8]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+ Octet 2-5: Password creation date in Macintosh format, defined
+ as 32 bits unsigned representing seconds since Midnight GMT
+ January 1, 1904.
+
+ Octet 6-9 Password Expiration Delta from create date in
+ seconds.
+
+ Octet 10-13: Current RADIUS time in Macintosh format
+
+ Optionally, a single Reply-Message with a text string up to 253
+ characters long which MAY be sent down to the user to be displayed
+ in a sign-on/message of the day dialog.
+
+ Framed-AppleTalk-Network may be included.
+
+ Framed-AppleTalk-Zone, up to 32 characters in length, may be
+ included.
+
+ ARAP defines the notion of a list of zones for a user. Along with
+ a list of zone names, a Zone Access Flag is defined (and used by
+ the NAS) which says how to use the list of zone names. That is,
+ the dial-in user may only be allowed to see the Default Zone, or
+ only the zones in the zone list (inclusive) or any zone except
+ those in the zone list (exclusive).
+
+ The ARAP NAS handles this by having a named filter which contains
+ (at least) zone names. This solves the problem where a single
+ RADIUS server is managing disparate NAS clients who may not be
+ able to "see" all of the zone names in a user zone list. Zone
+ names only have meaning "at the NAS." The disadvantage of this
+ approach is that zone filters must be set up on the NAS somehow,
+ then referenced by the RADIUS Filter-Id.
+
+ ARAP-Zone-Access contains an integer which specifies how the "zone
+ list" for this user should be used. If this attribute is present
+ and the value is 2 or 4 then a Filter-Id must also be present to
+ name a zone list filter to apply the access flag to.
+
+ The inclusion of a Callback-Number or Callback-Id attribute in the
+ Access-Accept MAY cause the ARAP NAS to disconnect after sending
+ the Feature Flags to begin callback processing in an ARAP specific
+ way.
+
+
+
+
+
+
+
+
+
+Rigney, et al. Informational [Page 9]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+ Other attributes may be present in the Access-Accept packet as well.
+
+ An ARAP NAS will need other information to finish bringing up the
+ connection to the dial in client, but this information can be
+ provided by the ARAP NAS without any help from RADIUS, either through
+ configuration by SNMP, a NAS administration program, or deduced by
+ the AppleTalk stack in the NAS. Specifically:
+
+ 1. AppearAsNet and AppearAsNode values, sent to the client to tell
+ it what network and node numbers it should use in its datagram
+ packets. AppearAsNet can be taken from the Framed-AppleTalk-
+ Network attribute or from the configuration or AppleTalk stack
+ onthe NAS.
+
+ 2. The "default" zone - that is the name of the AppleTalk zone in
+ which the dial-in client will appear. (Or can be specified
+ with the Framed-AppleTalk-Zone attribute.)
+
+ 3. Other very NAS specific stuff such as the name of the NAS, and
+ smartbuffering information. (Smartbuffering is an ARAP
+ mechanism for replacing common AppleTalk datagrams with small
+ tokens, to improve slow link performance in a few common
+ traffic situations.)
+
+ 4. "Zone List" information for this user. The ARAP specification
+ defines a "zone count" field which is actually unused.
+
+ RADIUS supports ARAP Security Modules in the following manner.
+
+ After DES authentication has been completed, the RADIUS server may
+ instruct the ARAP NAS to run one or more security modules for the
+ dial-in user. Although the underlying protocol supports executing
+ multiple security modules in series, in practice all current
+ implementations only allow executing one. Through the use of
+ multiple Access-Challenge requests, multiple modules can be
+ supported, but this facility will probably never be used.
+
+ We also assume that, even though ARAP allows a free-form dialog
+ between security modules on each end of the point-to-point link, in
+ actual practice all security modules can be reduced to a simple
+ challenge/response cycle.
+
+ If the RADIUS server wishes to instruct the ARAP NAS to run a
+ security module, it should send an Access-Challenge packet to the NAS
+ with (optionally) the State attribute, plus the ARAP-Challenge-
+ Response, ARAP-Features, and two more attributes:
+
+
+
+
+
+Rigney, et al. Informational [Page 10]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+ ARAP-Security: a four octet security module signature, containing a
+ Macintosh OSType.
+
+ ARAP-Security-Data, a string to carry the actual security module
+ challenge and response.
+
+ When the security module finishes executing, the security module
+ response is passed in an ARAP-Security-Data attribute from the NAS
+ to the RADIUS server in a second Access-Request, also including the
+ State from the Access-Challenge. The authenticator field contains no
+ special information in this case, and this can be discerned by the
+ presence of the State attribute.
+
+2.3. RADIUS Support for Extensible Authentication Protocol (EAP)
+
+ The Extensible Authentication Protocol (EAP), described in [3],
+ 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. In
+ order to provide for support of EAP within RADIUS, two new
+ attributes, EAP-Message and Message-Authenticator, are introduced in
+ this document. This section describes how these new attributes may be
+ used for providing EAP support within RADIUS.
+
+ In the proposed scheme, the RADIUS server is used to shuttle RADIUS-
+ encapsulated EAP Packets between the NAS and a backend security
+ server. While the conversation between the RADIUS server and the
+ backend security server will typically occur using a proprietary
+ protocol developed by the backend security server vendor, it is also
+ possible to use RADIUS-encapsulated EAP via the EAP-Message
+ attribute. This has the advantage of allowing the RADIUS server to
+ support EAP without the need for authentication-specific code, which
+ can instead reside on the backend security server.
+
+2.3.1. Protocol Overview
+
+ The EAP conversation between the authenticating peer (dial-in user)
+ and the NAS begins with the negotiation of EAP within LCP. Once EAP
+ has been negotiated, the NAS MUST send an EAP-Request/Identity
+ message to the authenticating peer, unless identity is determined via
+ some other means such as Called-Station-Id or Calling-Station-Id.
+ The peer will then respond with an EAP-Response/Identity which the
+ the NAS will then forward to the RADIUS server in the EAP-Message
+ attribute of a RADIUS Access-Request packet. The RADIUS Server will
+ typically use the EAP-Response/Identity to determine which EAP type
+ is to be applied to the user.
+
+
+
+
+Rigney, et al. Informational [Page 11]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+ In order to permit non-EAP aware RADIUS proxies to forward the
+ Access-Request packet, if the NAS sends the EAP-Request/Identity, the
+ NAS MUST copy the contents of the EAP-Response/Identity into the
+ User-Name attribute and MUST include the EAP-Response/Identity in the
+ User-Name attribute in every subsequent Access-Request. NAS-Port or
+ NAS-Port-Id SHOULD be included in the attributes issued by the NAS in
+ the Access-Request packet, and either NAS-Identifier or NAS-IP-
+ Address MUST be included. In order to permit forwarding of the
+ Access-Reply by EAP-unaware proxies, if a User-Name attribute was
+ included in an Access-Request, the RADIUS Server MUST include the
+ User-Name attribute in subsequent Access-Accept packets. Without the
+ User-Name attribute, accounting and billing becomes very difficult to
+ manage.
+
+ If identity is determined via another means such as Called-Station-Id
+ or Calling-Station-Id, the NAS MUST include these identifying
+ attributes in every Access-Request.
+
+ While this approach will save a round-trip, it cannot be universally
+ employed. There are circumstances in which the user's identity may
+ not be needed (such as when authentication and accounting is handled
+ based on Called-Station-Id or Calling-Station-Id), and therefore an
+ EAP-Request/Identity packet may not necessarily be issued by the NAS
+ to the authenticating peer. In cases where an EAP-Request/Identity
+ packet will not be sent, the NAS will send to the RADIUS server a
+ RADIUS Access-Request packet containing an EAP-Message attribute
+ signifying EAP-Start. EAP-Start is indicated by sending an EAP-
+ Message attribute with a length of 2 (no data). However, it should be
+ noted that since no User-Name attribute is included in the Access-
+ Request, this approach is not compatible with RADIUS as specified in
+ [1], nor can it easily be applied in situations where proxies are
+ deployed, such as roaming or shared use networks.
+
+ If the RADIUS server supports EAP, it MUST respond with an Access-
+ Challenge packet containing an EAP-Message attribute. If the RADIUS
+ server does not support EAP, it MUST respond with an Access-Reject.
+ The EAP-Message attribute includes an encapsulated EAP packet which
+ is then passed on to the authenticating peer. In the case where the
+ NAS does not initially send an EAP-Request/Identity message to the
+ peer, the Access-Challenge typically will contain an EAP-Message
+ attribute encapsulating an EAP-Request/Identity message, requesting
+ the dial-in user to identify themself. The NAS will then respond with
+ a RADIUS Access-Request packet containing an EAP-Message attribute
+ encapsulating an EAP-Response. The conversation continues until
+ either a RADIUS Access-Reject or Access-Accept packet is received.
+
+
+
+
+
+
+Rigney, et al. Informational [Page 12]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+ Reception of a RADIUS Access-Reject packet, with or without an EAP-
+ Message attribute encapsulating EAP-Failure, MUST result in the NAS
+ issuing an LCP Terminate Request to the authenticating peer. A
+ RADIUS Access-Accept packet with an EAP-Message attribute
+ encapsulating EAP-Success successfully ends the authentication phase.
+ The RADIUS Access-Accept/EAP-Message/EAP-Success packet MUST contain
+ all of the expected attributes which are currently returned in an
+ Access-Accept packet.
+
+ The above scenario creates a situation in which the NAS never needs
+ to manipulate an EAP packet. An alternative may be used in
+ situations where an EAP-Request/Identity message will always be sent
+ by the NAS to the authenticating peer.
+
+ For proxied RADIUS requests there are two methods of processing. If
+ the domain is determined based on the Called-Station-Id, the RADIUS
+ Server may proxy the initial RADIUS Access-Request/EAP-Start. If the
+ domain is determined based on the user's identity, the local RADIUS
+ Server MUST respond with a RADIUS Access-Challenge/EAP-Identity
+ packet. The response from the authenticating peer MUST be proxied to
+ the final authentication server.
+
+ For proxied RADIUS requests, the NAS may receive an Access-Reject
+ packet in response to its Access-Request/EAP-Identity packet. This
+ would occur if the message was proxied to a RADIUS Server which does
+ not support the EAP-Message extension. On receiving an Access-Reject,
+ the NAS MUST send an LCP Terminate Request to the authenticating
+ peer, and disconnect.
+
+2.3.2. Retransmission
+
+ As noted in [3], the EAP authenticator (NAS) is responsible for
+ retransmission of packets between the authenticating peer and the
+ NAS. Thus if an EAP packet is lost in transit between the
+ authenticating peer and the NAS (or vice versa), the NAS will
+ retransmit. As in RADIUS [1], the RADIUS client is responsible for
+ retransmission of packets between the RADIUS client and the RADIUS
+ server.
+
+ Note that it may be necessary to adjust retransmission strategies and
+ authentication timeouts in certain cases. For example, when a token
+ card is used additional time may be required to allow the user to
+ find the card and enter the token. Since the NAS will typically not
+ have knowledge of the required parameters, these need to be provided
+ by the RADIUS server. This can be accomplished by inclusion of
+ Session-Timeout and Password-Retry attributes within the Access-
+ Challenge packet.
+
+
+
+
+Rigney, et al. Informational [Page 13]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+ If Session-Timeout is present in an Access-Challenge packet that also
+ contains an EAP-Message, the value of the Session-Timeout provides
+ the NAS with the maximum number of seconds the NAS should wait for an
+ EAP-Response before retransmitting the EAP-Message to the dial-in
+ user.
+
+2.3.3. Fragmentation
+
+ Using the EAP-Message attribute, it is possible for the RADIUS server
+ to encapsulate an EAP packet that is larger than the MTU on the link
+ between the NAS and the peer. Since it is not possible for the RADIUS
+ server to use MTU discovery to ascertain the link MTU, the Framed-MTU
+ attribute may be included in an Access-Request packet containing an
+ EAP-Message attribute so as to provide the RADIUS server with this
+ information.
+
+2.3.4. Examples
+
+ The example below shows the conversation between the authenticating
+ peer, NAS, and RADIUS server, for the case of a One Time Password
+ (OTP) authentication. OTP is used only for illustrative purposes;
+ other authentication protocols could also have been used, although
+ they might show somewhat different behavior.
+
+Authenticating Peer NAS RADIUS Server
+------------------- --- -------------
+
+ <- PPP LCP Request-EAP
+ auth
+PPP LCP ACK-EAP
+auth ->
+ <- PPP EAP-Request/
+ Identity
+PPP EAP-Response/
+Identity (MyID) ->
+ RADIUS
+ Access-Request/
+ EAP-Message/
+ EAP-Response/
+ (MyID) ->
+ <- RADIUS
+ Access-Challenge/
+ EAP-Message/EAP-Request
+ OTP/OTP Challenge
+ <- PPP EAP-Request/
+ OTP/OTP Challenge
+PPP EAP-Response/
+OTP, OTPpw ->
+
+
+
+Rigney, et al. Informational [Page 14]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+ RADIUS
+ Access-Request/
+ EAP-Message/
+ EAP-Response/
+ OTP, OTPpw ->
+ <- RADIUS
+ Access-Accept/
+ EAP-Message/EAP-Success
+ (other attributes)
+ <- PPP EAP-Success
+PPP Authentication
+Phase complete,
+NCP Phase starts
+
+In the case where the NAS first sends an EAP-Start packet to the
+RADIUS server, the conversation would appear as follows:
+
+Authenticating Peer NAS RADIUS Server
+------------------- --- -------------
+
+ <- PPP LCP Request-EAP
+ auth
+PPP LCP ACK-EAP
+auth ->
+ RADIUS
+ Access-Request/
+ EAP-Message/Start ->
+ <- RADIUS
+ Access-Challenge/
+ EAP-Message/Identity
+ <- PPP EA-Request/
+ Identity
+PPP EAP-Response/
+Identity (MyID) ->
+ RADIUS
+ Access-Request/
+ EAP-Message/
+ EAP-Response/
+ (MyID) ->
+ <- RADIUS
+ Access-Challenge/
+ EAP-Message/EAP-Request
+ OTP/OTP Challenge
+ <- PPP EAP-Request/
+ OTP/OTP Challenge
+PPP EAP-Response/
+OTP, OTPpw ->
+
+
+
+
+Rigney, et al. Informational [Page 15]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+ RADIUS
+ Access-Request/
+ EAP-Message/
+ EAP-Response/
+ OTP, OTPpw ->
+ <- RADIUS
+ Access-Accept/
+ EAP-Message/EAP-Success
+ (other attributes)
+ <- PPP EAP-Success
+PPP Authentication
+Phase complete,
+NCP Phase starts
+
+In the case where the client fails EAP authentication, the
+conversation would appear as follows:
+
+Authenticating Peer NAS RADIUS Server
+------------------- --- -------------
+
+ <- PPP LCP Request-EAP
+ auth
+PPP LCP ACK-EAP
+auth ->
+ Access-Request/
+ EAP-Message/Start ->
+ <- RADIUS
+ Access-Challenge/
+ EAP-Message/Identity
+ <- PPP EAP-Request/
+ Identity
+PPP EAP-Response/
+Identity (MyID) ->
+ RADIUS
+ Access-Request/
+ EAP-Message/
+ EAP-Response/
+ (MyID) ->
+ <- RADIUS
+ Access-Challenge/
+ EAP-Message/EAP-Request
+ OTP/OTP Challenge
+ <- PPP EAP-Request/
+ OTP/OTP Challenge
+PPP EAP-Response/
+OTP, OTPpw ->
+ RADIUS
+ Access-Request/
+
+
+
+Rigney, et al. Informational [Page 16]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+ EAP-Message/
+ EAP-Response/
+ OTP, OTPpw ->
+ <- RADIUS
+ Access-Reject/
+ EAP-Message/EAP-Failure
+
+ <- PPP EAP-Failure
+ (client disconnected)
+
+In the case that the RADIUS server or proxy does not support
+EAP-Message, the conversation would appear as follows:
+
+Authenticating Peer NAS RADIUS Server
+------------------- --- -------------
+
+ <- PPP LCP Request-EAP
+ auth
+PPP LCP ACK-EAP
+auth ->
+ RADIUS
+ Access-Request/
+ EAP-Message/Start ->
+ <- RADIUS
+ Access-Reject
+ <- PPP LCP Terminate
+ (User Disconnected)
+
+In the case where the local RADIUS Server does support EAP-Message,
+but the remote RADIUS Server does not, the conversation would appear
+as follows:
+
+Authenticating Peer NAS RADIUS Server
+------------------- --- -------------
+
+ <- PPP LCP Request-EAP
+ auth
+PPP LCP ACK-EAP
+auth ->
+ RADIUS
+ Access-Request/
+ EAP-Message/Start ->
+ <- RADIUS
+ Access-Challenge/
+ EAP-Message/Identity
+ <- PPP EAP-Request/
+ Identity
+
+
+
+
+Rigney, et al. Informational [Page 17]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+PPP EAP-Response/
+Identity
+(MyID) ->
+ RADIUS
+ Access-Request/
+ EAP-Message/EAP-Response/
+ (MyID) ->
+ <- RADIUS
+ Access-Reject
+ (proxied from remote
+ RADIUS Server)
+ <- PPP LCP Terminate
+ (User Disconnected)
+
+In the case where the authenticating peer does not support EAP, but
+where EAP is required for that user, the conversation would appear as
+follows:
+
+Authenticating Peer NAS RADIUS Server
+------------------- --- -------------
+
+ <- PPP LCP Request-EAP
+ auth
+PPP LCP NAK-EAP
+auth ->
+ <- PPP LCP Request-CHAP
+ auth
+PPP LCP ACK-CHAP
+auth ->
+ <- PPP CHAP Challenge
+PPP CHAP Response ->
+ RADIUS
+ Access-Request/
+ User-Name,
+ CHAP-Password ->
+ <- RADIUS
+ Access-Reject
+ <- PPP LCP Terminate
+ (User Disconnected)
+
+In the case where the NAS does not support EAP, but where EAP is
+required for that user, the conversation would appear as follows:
+
+Authenticating Peer NAS RADIUS Server
+------------------- --- -------------
+
+ <- PPP LCP Request-CHAP
+ auth
+
+
+
+Rigney, et al. Informational [Page 18]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+PP LCP ACK-CHAP
+auth ->
+ <- PPP CHAP Challenge
+PPP CHAP Response ->
+ RADIUS
+ Access-Request/
+ User-Name,
+ CHAP-Password ->
+
+ <- RADIUS
+ Access-Reject
+ <- PPP LCP Terminate
+ (User Disconnected)
+
+2.3.5. Alternative uses
+
+ Currently the conversation between the backend security server and
+ the RADIUS server is proprietary because of lack of standardization.
+ In order to increase standardization and provide interoperability
+ between Radius vendors and backend security vendors, it is
+ recommended that RADIUS-encapsulated EAP be used for this
+ conversation.
+
+ This has the advantage of allowing the RADIUS server to support EAP
+ without the need for authentication-specific code within the RADIUS
+ server. Authentication-specific code can then reside on a backend
+ security server instead.
+
+ In the case where RADIUS-encapsulated EAP is used in a conversation
+ between a RADIUS server and a backend security server, the security
+ server will typically return an Access-Accept/EAP-Success message
+ without inclusion of the expected attributes currently returned in an
+ Access-Accept. This means that the RADIUS server MUST add these
+ attributes prior to sending an Access-Accept/EAP-Success message to
+ the NAS.
+
+3. Packet Format
+
+ Packet Format is identical to that defined in RFC 2865 [1] and 2866
+ [2].
+
+4. Packet Types
+
+ Packet types are identical to those defined in RFC 2865 [1] and 2866
+ [2].
+
+ See "Table of Attributes" below to determine which types of packets
+ can contain which attributes defined here.
+
+
+
+Rigney, et al. Informational [Page 19]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+5. Attributes
+
+ RADIUS Attributes carry the specific authentication, authorization
+ and accounting details for the request and response.
+
+ Some attributes MAY be included more than once. The effect of this
+ is attribute specific, and is specified in each attribute
+ description. The order of attributes of the same type SHOULD be
+ preserved. The order of attributes of different types is not
+ required to be preserved.
+
+ The end of the list of attributes is indicated by the Length of the
+ RADIUS packet.
+
+ A summary of the attribute format is the same as in RFC 2865 [1] but
+ is included here for ease of reference. 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 | Value ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ Type
+
+ The Type field is one octet. Up-to-date values of the RADIUS Type
+ field are specified in the most recent "Assigned Numbers" RFC [5].
+ Values 192-223 are reserved for experimental use, values 224-240
+ are reserved for implementation-specific use, and values 241-255
+ are reserved and should not be used. This specification concerns
+ the following values:
+
+ 1-39 (refer to RFC 2865 [1], "RADIUS")
+ 40-51 (refer to RFC 2866 [2], "RADIUS Accounting")
+ 52 Acct-Input-Gigawords
+ 53 Acct-Output-Gigawords
+ 54 Unused
+ 55 Event-Timestamp
+ 56-59 Unused
+ 60-63 (refer to RFC 2865 [1], "RADIUS")
+ 64-67 (refer to [6])
+ 68 (refer to [7])
+ 69 (refer to [6])
+ 70 ARAP-Password
+ 71 ARAP-Features
+ 72 ARAP-Zone-Access
+
+
+
+Rigney, et al. Informational [Page 20]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+ 73 ARAP-Security
+ 74 ARAP-Security-Data
+ 75 Password-Retry
+ 76 Prompt
+ 77 Connect-Info
+ 78 Configuration-Token
+ 79 EAP-Message
+ 80 Message-Authenticator
+ 81-83 (refer to [6])
+ 84 ARAP-Challenge-Response
+ 85 Acct-Interim-Interval
+ 86 (refer to [7])
+ 87 NAS-Port-Id
+ 88 Framed-Pool
+ 89 Unused
+ 90-91 (refer to [6])
+ 92-191 Unused
+
+ Length
+
+ The Length field is one octet, and indicates the length of this
+ attribute including the Type, Length and Value fields. If an
+ attribute is received in a packet with an invalid Length, the
+ entire request should be silently discarded.
+
+ Value
+
+ The Value field is zero or more octets and contains information
+ specific to the attribute. The format and length of the Value
+ field is determined by the Type and Length fields.
+
+ Note that none of the types in RADIUS terminate with a NUL (hex
+ 00). In particular, types "text" and "string" in RADIUS do not
+ terminate with a NUL (hex 00). The Attribute has a length field
+ and does not use a terminator. Text contains UTF-8 encoded 10646
+ [8] characters and String contains 8-bit binary data. Servers and
+ servers and clients MUST be able to deal with embedded nulls.
+ RADIUS implementers using C are cautioned not to use strcpy() when
+ handling strings.
+
+ The format of the value field is one of five data types. Note
+ that type "text" is a subset of type "string."
+
+ text 1-253 octets containing UTF-8 encoded 10646 [8]
+ characters. Text of length zero (0) MUST NOT be sent;
+ omit the entire attribute instead.
+
+
+
+
+
+Rigney, et al. Informational [Page 21]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+ string 1-253 octets containing binary data (values 0 through
+ 255 decimal, inclusive). Strings of length zero (0) MUST
+ NOT be sent; omit the entire attribute instead.
+
+ address 32 bit unsigned value, most significant octet first.
+
+ integer 32 bit unsigned value, most significant octet first.
+
+ time 32 bit unsigned value, most significant octet first --
+ seconds since 00:00:00 UTC, January 1, 1970.
+
+5.1. Acct-Input-Gigawords
+
+ Description
+
+ This attribute indicates how many times the Acct-Input-Octets
+ counter has wrapped around 2^32 over the course of this service
+ being provided, and can only be present in Accounting-Request
+ records where the Acct-Status-Type is set to Stop or Interim-
+ Update.
+
+ A summary of the Acct-Input-Gigawords attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 52 for Acct-Input-Gigawords.
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets.
+
+
+
+
+
+
+
+
+Rigney, et al. Informational [Page 22]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+5.2. Acct-Output-Gigawords
+
+ Description
+
+ This attribute indicates how many times the Acct-Output-Octets
+ counter has wrapped around 2^32 in the course of delivering this
+ service, and can only be present in Accounting-Request records
+ where the Acct-Status-Type is set to Stop or Interim-Update.
+
+ A summary of the Acct-Output-Gigawords attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 53 for Acct-Output-Gigawords.
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets.
+
+5.3. Event-Timestamp
+
+ Description
+
+ This attribute is included in an Accounting-Request packet to
+ record the time that this event occurred on the NAS, in seconds
+ since January 1, 1970 00:00 UTC.
+
+ A summary of the Event-Timestamp attribute format is shown below.
+ The fields are transmitted from left to right.
+
+
+
+
+
+
+
+
+
+Rigney, et al. Informational [Page 23]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+ 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 55 for Event-Timestamp
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets encoding an unsigned integer with
+ the number of seconds since January 1, 1970 00:00 UTC.
+
+5.4. ARAP-Password
+
+ Description
+
+ This attribute is only present in an Access-Request packet
+ containing a Framed-Protocol of ARAP.
+
+ Only one of User-Password, CHAP-Password, or ARAP-Password needs
+ to be present in an Access-Request, or one or more EAP-Messages.
+
+ A summary of the ARAP-Password attribute 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 | Value1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Value2
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Value3
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Value4
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+Rigney, et al. Informational [Page 24]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+ Type
+
+ 70 for ARAP-Password.
+
+ Length
+
+ 18
+
+ Value
+
+ This attribute contains a 16 octet string, used to carry the
+ dial-in user's response to the NAS challenge and the client's own
+ challenge to the NAS. The high-order octets (Value1 and Value2)
+ contain the dial-in user's challenge to the NAS (2 32-bit numbers,
+ 8 octets) and the low-order octets (Value3 and Value4) contain the
+ dial-in user's response to the NAS challenge (2 32-bit numbers, 8
+ octets).
+
+5.5. ARAP-Features
+
+ Description
+
+ This attribute is sent in an Access-Accept packet with Framed-
+ Protocol of ARAP, and includes password information that the NAS
+ should sent to the user in an ARAP "feature flags" packet.
+
+ A summary of the ARAP-Features attribute 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 | Value1 | Value2 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Value3 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Value4 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Value5 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 71 for ARAP-Features.
+
+ Length
+
+ 16
+
+
+
+Rigney, et al. Informational [Page 25]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+ Value
+
+ The Value field is a compound string containing information the
+ NAS should send to the user in the ARAP "feature flags" packet.
+
+ Value1: If zero, user cannot change their password. If non-zero
+ user can. (RADIUS does not handle the password changing, just
+ the attribute which indicates whether ARAP indicates they can.)
+
+ Value2: Minimum acceptable password length, from 0 to 8.
+
+ Value3: Password creation date in Macintosh format, defined as
+ 32 unsigned bits representing seconds since Midnight GMT
+ January 1, 1904.
+
+ Value4: Password Expiration Delta from create date in seconds.
+
+ Value5: Current RADIUS time in Macintosh format.
+
+5.6. ARAP-Zone-Access
+
+ Description
+
+ This attribute is included in an Access-Accept packet with
+ Framed-Protocol of ARAP to indicate how the ARAP zone list for the
+ user should be used.
+
+ A summary of the ARAP-Zone-Access attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ Type
+
+ 72 for ARAP-Zone-Access.
+
+ Length
+
+ 6
+
+
+
+
+
+Rigney, et al. Informational [Page 26]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+ Value
+
+ The Value field is four octets encoding an integer with one of the
+ following values:
+
+ 1 Only allow access to default zone
+ 2 Use zone filter inclusively
+ 4 Use zone filter exclusively
+
+
+ The value 3 is skipped, not because these are bit flags, but
+ because 3 in some ARAP implementations means "all zones" which is
+ the same as not specifying a list at all under RADIUS.
+
+ If this attribute is present and the value is 2 or 4 then a
+ Filter-Id must also be present to name a zone list filter to apply
+ the access flag to.
+
+5.7. ARAP-Security
+
+ Description
+
+ This attribute identifies the ARAP Security Module to be used in
+ an Access-Challenge packet.
+
+ A summary of the ARAP-Security attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 73 for ARAP-Security.
+
+ Length
+
+ 6
+
+
+
+
+
+
+
+
+Rigney, et al. Informational [Page 27]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+ Value
+
+ The Value field is four octets, containing an integer specifying
+ the security module signature, which is a Macintosh OSType.
+ (Macintosh OSTypes are 4 ascii characters cast as a 32-bit
+ integer)
+
+5.8. ARAP-Security-Data
+
+ Description
+
+ This attribute contains the actual security module challenge or
+ response, and can be found in Access-Challenge and Access-Request
+ packets.
+
+ A summary of the ARAP-Security-Data attribute 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 | String...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 74 for ARAP-Security-Data.
+
+ Length
+
+ >=3
+
+ String
+
+ The String field contains the security module challenge or
+ response associated with the ARAP Security Module specified in
+ ARAP-Security.
+
+5.9. Password-Retry
+
+ Description
+
+ This attribute MAY be included in an Access-Reject to indicate how
+ many authentication attempts a user may be allowed to attempt
+ before being disconnected.
+
+ It is primarily intended for use with ARAP authentication.
+
+
+
+
+Rigney, et al. Informational [Page 28]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+ A summary of the Password-Retry attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 75 for Password-Retry.
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets, containing an integer specifying
+ the number of password retry attempts to permit the user.
+
+5.10. Prompt
+
+ Description
+
+ This attribute is used only in Access-Challenge packets, and
+ indicates to the NAS whether it should echo the user's response as
+ it is entered, or not echo it.
+
+
+ A summary of the Prompt attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 76 for Prompt.
+
+
+
+
+Rigney, et al. Informational [Page 29]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets.
+
+ 0 No Echo
+ 1 Echo
+
+5.11. Connect-Info
+
+ Description
+
+ This attribute is sent from the NAS to indicate the nature of the
+ user's connection.
+
+ The NAS MAY send this attribute in an Access-Request or
+ Accounting-Request to indicate the nature of the user's
+ connection.
+
+ A summary of the Connect-Info attribute 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 | Text...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 77 for Connect-Info.
+
+ Length
+
+ >= 3
+
+ Text
+
+ The Text field consists of UTF-8 encoded 10646 [8] characters.
+ The connection speed SHOULD be included at the beginning of the
+ first Connect-Info attribute in the packet. If the transmit and
+ receive connection speeds differ, they may both be included in the
+ first attribute with the transmit speed first (the speed the NAS
+ modem transmits at), a slash (/), the receive speed, then
+ optionally other information.
+
+
+
+Rigney, et al. Informational [Page 30]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+ For example, "28800 V42BIS/LAPM" or "52000/31200 V90"
+
+ More than one Connect-Info attribute may be present in an
+ Accounting-Request packet to accommodate expected efforts by ITU
+ to have modems report more connection information in a standard
+ format that might exceed 252 octets.
+
+5.12. Configuration-Token
+
+ Description
+
+ This attribute is for use in large distributed authentication
+ networks based on proxy. It is sent from a RADIUS Proxy Server to
+ a RADIUS Proxy Client in an Access-Accept to indicate a type of
+ user profile to be used. It should not be sent to a NAS.
+
+ A summary of the Configuration-Token attribute 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 | String ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 78 for Configuration-Token.
+
+ Length
+
+ >= 3
+
+ String
+
+ The String field is one or more octets. The actual format of the
+ information is site or application specific, and a robust
+ implementation SHOULD support the field as undistinguished octets.
+
+ The codification of the range of allowed usage of this field is
+ outside the scope of this specification.
+
+
+
+
+
+
+
+
+
+
+Rigney, et al. Informational [Page 31]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+5.13. EAP-Message
+
+ Description
+
+ This attribute encapsulates Extended Access Protocol [3] packets
+ so as to allow the NAS to authenticate dial-in users via EAP
+ without having to understand the EAP protocol.
+
+ The NAS places any EAP messages received from the user into one or
+ more EAP attributes and forwards them to the RADIUS Server as part
+ of the Access-Request, which can return EAP messages in Access-
+ Challenge, Access-Accept and Access-Reject packets.
+
+ A RADIUS Server receiving EAP messages that it does not understand
+ SHOULD return an Access-Reject.
+
+ The NAS places EAP messages received from the authenticating peer
+ into one or more EAP-Message attributes and forwards them to the
+ RADIUS Server within an Access-Request message. If multiple EAP-
+ Messages are contained within an Access-Request or Access-
+ Challenge packet, they MUST be in order and they MUST be
+ consecutive attributes in the Access-Request or Access-Challenge
+ packet. Access-Accept and Access-Reject packets SHOULD only have
+ ONE EAP-Message attribute in them, containing EAP-Success or EAP-
+ Failure.
+
+ It is expected that EAP will be used to implement a variety of
+ authentication methods, including methods involving strong
+ cryptography. In order to prevent attackers from subverting EAP by
+ attacking RADIUS/EAP, (for example, by modifying the EAP-Success
+ or EAP-Failure packets) it is necessary that RADIUS/EAP provide
+ integrity protection at least as strong as those used in the EAP
+ methods themselves.
+
+ Therefore the Message-Authenticator attribute MUST be used to
+ protect all Access-Request, Access-Challenge, Access-Accept, and
+ Access-Reject packets containing an EAP-Message attribute.
+
+ Access-Request packets including an EAP-Message attribute without
+ a Message-Authenticator attribute SHOULD be silently discarded by
+ the RADIUS server. A RADIUS Server supporting EAP-Message MUST
+ calculate the correct value of the Message-Authenticator and
+ silently discard the packet if it does not match the value sent.
+ A RADIUS Server not supporting EAP-Message MUST return an Access-
+ Reject if it receives an Access-Request containing an EAP-Message
+ attribute. A RADIUS Server receiving an EAP-Message attribute that
+ it does not understand MUST return an Access-Reject.
+
+
+
+
+Rigney, et al. Informational [Page 32]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+ Access-Challenge, Access-Accept, or Access-Reject packets
+ including an EAP-Message attribute without a Message-Authenticator
+ attribute SHOULD be silently discarded by the NAS. A NAS
+ supporting EAP-Message MUST calculate the correct value of the
+ Message-Authenticator and silently discard the packet if it does
+ not match the value sent.
+
+ A summary of the EAP-Message attribute 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 | String...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 79 for EAP-Message.
+
+ Length
+
+ >= 3
+
+ String
+
+ The String field contains EAP packets, as defined in [3]. If
+ multiple EAP-Message attributes are present in a packet their
+ values should be concatenated; this allows EAP packets longer than
+ 253 octets to be passed by RADIUS.
+
+5.14. Message-Authenticator
+
+ Description
+
+ This attribute MAY be used to sign Access-Requests to prevent
+ spoofing Access-Requests using CHAP, ARAP or EAP authentication
+ methods. It MAY be used in any Access-Request. It MUST be used
+ in any Access-Request, Access-Accept, Access-Reject or Access-
+ Challenge that includes an EAP-Message attribute.
+
+ A RADIUS Server receiving an Access-Request with a Message-
+ Authenticator Attribute present MUST calculate the correct value
+ of the Message-Authenticator and silently discard the packet if it
+ does not match the value sent.
+
+
+
+
+
+
+Rigney, et al. Informational [Page 33]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+ A RADIUS Client receiving an Access-Accept, Access-Reject or
+ Access-Challenge with a Message-Authenticator Attribute present
+ MUST calculate the correct value of the Message-Authenticator and
+ silently discard the packet if it does not match the value sent.
+
+ Earlier drafts of this memo used "Signature" as the name of this
+ attribute, but Message-Authenticator is more precise. Its
+ operation has not changed, just the name.
+
+ A summary of the Message-Authenticator attribute 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 | String...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 80 for Message-Authenticator
+
+ Length
+
+ 18
+
+ String
+
+ When present in an Access-Request packet, Message-Authenticator is
+ an HMAC-MD5 [9] checksum of the entire Access-Request packet,
+ including Type, ID, Length and authenticator, using the shared
+ secret as the key, as follows.
+
+ Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
+ Request Authenticator, Attributes)
+
+ When the checksum is calculated the signature string should be
+ considered to be sixteen octets of zero.
+
+ For Access-Challenge, Access-Accept, and Access-Reject packets,
+ the Message-Authenticator is calculated as follows, using the
+ Request-Authenticator from the Access-Request this packet is in
+ reply to:
+
+ Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
+ Request Authenticator, Attributes)
+
+
+
+
+
+Rigney, et al. Informational [Page 34]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+ When the checksum is calculated the signature string should be
+ considered to be sixteen octets of zero. The shared secret is
+ used as the key for the HMAC-MD5 hash. The is calculated and
+ inserted in the packet before the Response Authenticator is
+ calculated.
+
+ This attribute is not needed if the User-Password attribute is
+ present, but is useful for preventing attacks on other types of
+ authentication. This attribute is intended to thwart attempts by
+ an attacker to setup a "rogue" NAS, and perform online dictionary
+ attacks against the RADIUS server. It does not afford protection
+ against "offline" attacks where the attacker intercepts packets
+ containing (for example) CHAP challenge and response, and performs
+ a dictionary attack against those packets offline.
+
+ IP Security will eventually make this attribute unnecessary, so it
+ should be considered an interim measure.
+
+5.15. ARAP-Challenge-Response
+
+ Description
+
+ This attribute is sent in an Access-Accept packet with Framed-
+ Protocol of ARAP, and contains the response to the dial-in
+ client's challenge.
+
+ A summary of the ARAP-Challenge-Response attribute 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 | Value...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 84 for ARAP-Challenge-Response.
+
+ Length
+
+ 10
+
+
+
+
+
+Rigney, et al. Informational [Page 35]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+ Value
+
+ The Value field contains an 8 octet response to the dial-in
+ client's challenge. The RADIUS server calculates this value by
+ taking the dial-in client's challenge from the high order 8 octets
+ of the ARAP-Password attribute and performing DES encryption on
+ this value with the authenticating user's password as the key. If
+ the user's password is less than 8 octets in length, the password
+ is padded at the end with NULL octets to a length of 8 before
+ using it as a key.
+
+5.16. Acct-Interim-Interval
+
+ Description
+
+ This attribute indicates the number of seconds between each
+ interim update in seconds for this specific session. This value
+ can only appear in the Access-Accept message.
+
+ A summary of the Acct-Interim-Interval attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 85 for Acct-Interim-Interval.
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field contains the number of seconds between each
+ interim update to be sent from the NAS for this session. The value
+ MUST NOT be smaller than 60. The value SHOULD NOT be smaller than
+ 600, and careful consideration should be given to its impact on
+ network traffic.
+
+
+
+
+
+
+Rigney, et al. Informational [Page 36]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+5.17. NAS-Port-Id
+
+ Description
+
+ This Attribute contains a text string which identifies the port of
+ the NAS which is authenticating the user. It is only used in
+ Access-Request and Accounting-Request packets. Note that this is
+ using "port" in its sense of a physical connection on the NAS, not
+ in the sense of a TCP or UDP port number.
+
+ Either NAS-Port or NAS-Port-Id SHOULD be present in an Access-
+ Request packet, if the NAS differentiates among its ports. NAS-
+ Port-Id is intended for use by NASes which cannot conveniently
+ number their ports.
+
+ A summary of the NAS-Port-Id Attribute 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 | Text...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ Type
+
+ 87 for NAS-Port-Id.
+
+ Length
+
+ >= 3
+
+ Text
+
+ The Text field contains the name of the port using UTF-8 encoded
+ 10646 [8] characters.
+
+5.18. Framed-Pool
+
+ Description
+
+ This Attribute contains the name of an assigned address pool that
+ SHOULD be used to assign an address for the user. If a NAS does
+ not support multiple address pools, the NAS should ignore this
+ Attribute. Address pools are usually used for IP addresses, but
+ can be used for other protocols if the NAS supports pools for
+ those protocols.
+
+
+
+Rigney, et al. Informational [Page 37]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+ A summary of the Framed-Pool Attribute 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 | String...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 88 for Framed-Pool
+
+ Length
+
+ >= 3
+
+ String
+
+ The string field contains the name of an assigned address pool
+ configured on the NAS.
+
+5.19. Table of Attributes
+
+ The following table provides a guide to which attributes may be found
+ in which kind of packets. Acct-Input-Gigawords, Acct-Output-
+ Gigawords, Event-Timestamp, and NAS-Port-Id may have 0-1 instances in
+ an Accounting-Request packet. Connect-Info may have 0+ instances in
+ an Accounting-Request packet. The other attributes added in this
+ document must not be present in an Accounting-Request.
+
+Request Accept Reject Challenge # Attribute
+0-1 0 0 0 70 ARAP-Password [Note 1]
+0 0-1 0 0-1 71 ARAP-Features
+0 0-1 0 0 72 ARAP-Zone-Access
+0-1 0 0 0-1 73 ARAP-Security
+0+ 0 0 0+ 74 ARAP-Security-Data
+0 0 0-1 0 75 Password-Retry
+0 0 0 0-1 76 Prompt
+0-1 0 0 0 77 Connect-Info
+0 0+ 0 0 78 Configuration-Token
+0+ 0+ 0+ 0+ 79 EAP-Message [Note 1]
+0-1 0-1 0-1 0-1 80 Message-Authenticator [Note 1]
+0 0-1 0 0-1 84 ARAP-Challenge-Response
+0 0-1 0 0 85 Acct-Interim-Interval
+0-1 0 0 0 87 NAS-Port-Id
+0 0-1 0 0 88 Framed-Pool
+Request Accept Reject Challenge # Attribute
+
+
+
+Rigney, et al. Informational [Page 38]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+ [Note 1] An Access-Request that contains either a User-Password or
+ CHAP-Password or ARAP-Password or one or more EAP-Message attributes
+ MUST NOT contain more than one type of those four attributes. If it
+ does not contain any of those four attributes, it SHOULD contain a
+ Message-Authenticator. If any packet type contains an EAP-Message
+ attribute it MUST also contain a Message-Authenticator.
+
+ The following table defines the above table entries.
+
+ 0 This attribute MUST NOT be present
+ 0+ Zero or more instances of this attribute MAY be present.
+ 0-1 Zero or one instance of this attribute MAY be present.
+ 1 Exactly one instance of this attribute MUST be present.
+
+6. IANA Considerations
+
+ The Packet Type Codes, Attribute Types, and Attribute Values defined
+ in this document are registered by the Internet Assigned Numbers
+ Authority (IANA) from the RADIUS name spaces as described in the
+ "IANA Considerations" section of [1], in accordance with BCP 26 [10].
+
+7. Security Considerations
+
+ The attributes other than Message-Authenticator and EAP-Message in
+ this document have no additional security considerations beyond those
+ already identified in [1].
+
+7.1. Message-Authenticator Security
+
+ Access-Request packets with a User-Password establish the identity of
+ both the user and the NAS sending the Access-Request, because of the
+ way the shared secret between NAS and RADIUS server is used.
+ Access-Request packets with CHAP-Password or EAP-Message do not have
+ a User-Password attribute, so the Message-Authenticator attribute
+ should be used in access-request packets that do not have a User-
+ Password, in order to establish the identity of the NAS sending the
+ request.
+
+7.2. EAP Security
+
+ Since the purpose of EAP is to provide enhanced security for PPP
+ authentication, it is critical that RADIUS support for EAP be secure.
+ In particular, the following issues must be addressed:
+
+ Separation of EAP server and PPP authenticator
+ Connection hijacking
+ Man in the middle attacks
+ Multiple databases
+
+
+
+Rigney, et al. Informational [Page 39]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+ Negotiation attacks
+
+7.2.1. Separation of EAP server and PPP authenticator
+
+ It is possible for the EAP endpoints to mutually authenticate,
+ negotiate a ciphersuite, and derive a session key for subsequent use
+ in PPP encryption.
+
+ This does not present an issue on the peer, since the peer and EAP
+ client reside on the same machine; all that is required is for the
+ EAP client module to pass the session key to the PPP encryption
+ module.
+
+ The situation is more complex when EAP is used with RADIUS, since the
+ PPP authenticator will typically not reside on the same machine as
+ the EAP server. For example, the EAP server may be a backend security
+ server, or a module residing on the RADIUS server.
+
+ In the case where the EAP server and PPP authenticator reside on
+ different machines, there are several implications for security.
+ Firstly, mutual authentication will occur between the peer and the
+ EAP server, not between the peer and the authenticator. This means
+ that it is not possible for the peer to validate the identity of the
+ NAS or tunnel server that it is speaking to.
+
+ As described earlier, when EAP/RADIUS is used to encapsulate EAP
+ packets, the Message-Authenticator attribute is required in
+ EAP/RADIUS Access-Requests sent from the NAS or tunnel server to the
+ RADIUS server. Since the Message-Authenticator attribute involves a
+ HMAC-MD5 hash, it is possible for the RADIUS server to verify the
+ integrity of the Access-Request as well as the NAS or tunnel server's
+ identity. Similarly, Access-Challenge packets sent from the RADIUS
+ server to the NAS are also authenticated and integrity protected
+ using an HMAC-MD5 hash, enabling the NAS or tunnel server to
+ determine the integrity of the packet and verify the identity of the
+ RADIUS server. Moreover, EAP packets sent via methods that contain
+ their own integrity protection cannot be successfully modified by a
+ rogue NAS or tunnel server.
+
+ The second issue that arises in the case of an EAP server and PPP
+ authenticator residing on different machines 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 outside the scope of this
+ document.
+
+
+
+
+Rigney, et al. Informational [Page 40]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+7.2.2. Connection hijacking
+
+ In this form of attack, the attacker attempts to inject packets into
+ the conversation between the NAS and the RADIUS server, or between
+ the RADIUS server and the backend security server. RADIUS does not
+ support encryption, and as described in [1], only Access-Reply and
+ Access-Challenge packets are integrity protected. Moreover, the
+ integrity protection mechanism described in [1] is weaker than that
+ likely to be used by some EAP methods, making it possible to subvert
+ those methods by attacking EAP/RADIUS.
+
+ In order to provide for authentication of all packets in the EAP
+ exchange, all EAP/RADIUS packets MUST be authenticated using the
+ Message-Authenticator attribute, as described previously.
+
+7.2.3. Man in the middle attacks
+
+ Since RADIUS security is based on shared secrets, end-to-end security
+ is not provided in the case where authentication or accounting
+ packets are forwarded along a proxy chain. As a result, attackers
+ gaining control of a RADIUS proxy will be able to modify EAP packets
+ in transit.
+
+7.2.4. Multiple databases
+
+ In many cases a backend security server will be deployed along with a
+ RADIUS server in order to provide EAP services. Unless the backend
+ security server also functions as a RADIUS server, two separate user
+ databases will exist, each containing information about the security
+ requirements for the user. This represents a weakness, since security
+ may be compromised by a successful attack on either of the servers,
+ or their backend databases. With multiple user databases, adding a
+ new user may require multiple operations, increasing the chances for
+ error. The problems are further magnified in the case where user
+ information is also being kept in an LDAP server. In this case, three
+ stores of user information may exist.
+
+ In order to address these threats, consolidation of databases is
+ recommended. This can be achieved by having both the RADIUS server
+ and backend security server store information in the same backend
+ database; by having the backend security server provide a full RADIUS
+ implementation; or by consolidating both the backend security server
+ and the RADIUS server onto the same machine.
+
+
+
+
+
+
+
+
+Rigney, et al. Informational [Page 41]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+7.2.5. Negotiation attacks
+
+ In a negotiation attack, a rogue NAS, tunnel server, RADIUS proxy or
+ RADIUS server causes the authenticating peer to choose a less secure
+ authentication method so as to make it easier to obtain the user's
+ password. For example, a session that would normally be authenticated
+ with EAP would instead authenticated via CHAP or PAP; alternatively,
+ a connection that would normally be authenticated via one EAP type
+ occurs via a less secure EAP type, such as MD5. The threat posed by
+ rogue devices, once thought to be remote, has gained currency given
+ compromises of telephone company switching systems, such as those
+ described in [11].
+
+ Protection against negotiation attacks requires the elimination of
+ downward negotiations. This can be achieved via implementation of
+ per-connection policy on the part of the authenticating peer, and
+ per-user policy on the part of the RADIUS server.
+
+ For the authenticating peer, authentication policy should be set on a
+ per-connection basis. Per-connection policy allows an authenticating
+ peer to negotiate EAP when calling one service, while negotiating
+ CHAP for another service, even if both services are accessible via
+ the same phone number.
+
+ With per-connection policy, an authenticating peer will only attempt
+ to negotiate EAP for a session in which EAP support is expected. As a
+ result, there is a presumption that an authenticating peer selecting
+ EAP requires that level of security. If it cannot be provided, it is
+ likely that there is some kind of misconfiguration, or even that the
+ authenticating peer is contacting the wrong server. Should the NAS
+ not be able to negotiate EAP, or should the EAP-Request sent by the
+ NAS be of a different EAP type than what is expected, the
+ authenticating peer MUST disconnect. An authenticating peer expecting
+ EAP to be negotiated for a session MUST NOT negotiate CHAP or PAP.
+
+ For a NAS, it may not be possible to determine whether a user is
+ required to authenticate with EAP until the user's identity is known.
+ For example, for shared-uses NASes it is possible for one reseller to
+ implement EAP while another does not. In such cases, if any users of
+ the NAS MUST do EAP, then the NAS MUST attempt to negotiate EAP for
+ every call. This avoids forcing an EAP-capable client to do more than
+ one authentication, which weakens security.
+
+ If CHAP is negotiated, the NAS will pass the User-Name and CHAP-
+ Password attributes to the RADIUS Server in an Access-Request packet.
+ If the user is not required to use EAP, then the RADIUS Server will
+ respond with an Access-Accept or Access-Reject packet as appropriate.
+ However, if CHAP has been negotiated but EAP is required, the RADIUS
+
+
+
+Rigney, et al. Informational [Page 42]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+ server MUST respond with an Access-Reject, rather than an Access-
+ Challenge/EAP-Message/EAP-Request packet. The authenticating peer
+ MUST refuse to renegotiate authentication, even if the renegotiation
+ is from CHAP to EAP.
+
+ If EAP is negotiated but is not supported by the RADIUS proxy or
+ server, then the server or proxy MUST respond with an Access-Reject.
+ In these cases, the NAS MUST send an LCP-Terminate and disconnect the
+ user. This is the correct behavior since the authenticating peer is
+ expecting EAP to be negotiated, and that expectation cannot be
+ fulfilled. An EAP-capable authenticating peer MUST refuse to
+ renegotiate the authentication protocol if EAP had initially been
+ negotiated. Note that problems with a non-EAP capable RADIUS proxy
+ could prove difficult to diagnose, since a user dialing in from one
+ location (with an EAP-capable proxy) might be able to successfully
+ authenticate via EAP, while the same user dialing into another
+ location (and encountering an EAP-incapable proxy) might be
+ consistently disconnected.
+
+8. References
+
+ [1] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
+ Authentication Dial In User Service (RADIUS)", RFC 2865, June
+ 2000.
+
+ [2] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
+
+ [3] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
+ Protocol (EAP)", RFC 2284, March 1998.
+
+ [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March, 1997.
+
+ [5] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
+ October 1994.
+
+ [6] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and
+ I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC
+ 2868, June 2000.
+
+ [7] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting
+ Modifications for Tunnel Protocol Support", RFC 2867, June 2000.
+
+ [8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
+ 2279, January 1998.
+
+
+
+
+
+
+Rigney, et al. Informational [Page 43]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+ [9] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
+ for Message Authentication", RFC 2104, February 1997.
+
+ [10] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
+ Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+ [11] Slatalla, M., and Quittner, J., "Masters of Deception."
+ HarperCollins, New York, 1995.
+
+9. Acknowledgements
+
+ RADIUS and RADIUS Accounting were originally developed by Livingston
+ Enterprises (now part of Lucent Technologies) for their PortMaster
+ series of Network Access Servers.
+
+ The section on ARAP is adopted with permission from "Using RADIUS to
+ Authenticate Apple Remote Access Connections" by Ward Willats of Cyno
+ Technologies (ward@cyno.com).
+
+ The section on Acct-Interim-Interval is adopted with permission from
+ an earlier work in progress by Pat Calhoun of Sun Microsystems, Mark
+ Beadles of Compuserve, and Alex Ratcliffe of UUNET Technologies.
+
+ The section on EAP is adopted with permission from an earlier work in
+ progress by Pat Calhoun of Sun Microsystems, Allan Rubens of Merit
+ Network, and Bernard Aboba of Microsoft. Thanks also to Dave Dawson
+ and Karl Fox of Ascend, and Glen Zorn and Narendra Gidwani of
+ Microsoft for useful discussions of this problem space.
+
+10. Chair's Address
+
+ The RADIUS working group can be contacted via the current chair:
+
+ Carl Rigney
+ Livingston Enterprises
+ 4464 Willow Road
+ Pleasanton, California 94588
+
+ Phone: +1 925 737 2100
+ EMail: cdr@telemancy.com
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et al. Informational [Page 44]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+11. Authors' Addresses
+
+ Questions about this memo can also be directed to:
+
+ Carl Rigney
+ Livingston Enterprises
+ 4464 Willow Road
+ Pleasanton, California 94588
+
+ EMail: cdr@telemancy.com
+
+ Questions on ARAP and RADIUS may be directed to:
+
+ Ward Willats
+ Cyno Technologies
+ 1082 Glen Echo Ave
+ San Jose, CA 95125
+
+ Phone: +1 408 297 7766
+ EMail: ward@cyno.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et al. Informational [Page 45]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+ Questions on EAP and RADIUS may be directed to any of the following:
+
+ Pat R. Calhoun
+ Network and Security Research Center
+ Sun Microsystems, Inc.
+ 15 Network Circle
+ Menlo Park, CA 94025
+
+ Phone: +1 650 786 7733
+ EMail: pcalhoun@eng.sun.com
+
+
+ Allan C. Rubens
+ Tut Systems, Inc.
+ 220 E. Huron, Suite 260
+ Ann Arbor, MI 48104
+
+ Phone: +1 734 995 1697
+ EMail: arubens@tutsys.com
+
+
+ Bernard Aboba
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052
+
+ Phone: +1 425 936 6605
+ EMail: bernarda@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et al. Informational [Page 46]
+
+RFC 2869 RADIUS Extensions June 2000
+
+
+12. 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et al. Informational [Page 47]
+
diff --git a/rfc/rfc3078.txt b/rfc/rfc3078.txt
new file mode 100644
index 0000000..5bbcc13
--- /dev/null
+++ b/rfc/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/rfc/rfc3079.txt b/rfc/rfc3079.txt
new file mode 100644
index 0000000..4d7ba0d
--- /dev/null
+++ b/rfc/rfc3079.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Network Working Group G. Zorn
+Request for Comments: 3079 cisco Systems
+Category: Informational March 2001
+
+
+ Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE)
+
+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.
+
+ Microsoft Point to Point Encryption (MPPE) is a means of representing
+ PPP packets in an encrypted form. MPPE uses the RSA RC4 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, 56-bit and 128-bit session keys. 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 in the Compression Control Protocol.
+
+ This document describes the method used to derive initial MPPE
+ session keys from a variety of credential types. It is expected that
+ this memo will be updated whenever Microsoft defines a new key
+ derivation method for MPPE, since its primary purpose is to provide
+ an open, easily accessible reference for third-parties wishing to
+ interoperate with Microsoft products.
+
+ MPPE itself (including the protocol used to negotiate its use, the
+ details of the encryption method used and the algorithm used to
+ change session keys during a session) is described in RFC 3078.
+
+
+
+
+
+
+
+Zorn Informational [Page 1]
+
+RFC 3079 MPPE Key Derivation March 2001
+
+
+Table of Contents
+
+ 1. Specification of Requirements ............................... 2
+ 2. Deriving Session Keys from MS-CHAP Credentials .............. 2
+ 2.1. Generating 40-bit Session Keys ............................ 3
+ 2.2. Generating 56-bit Session Keys ............................ 3
+ 2.3. Generating 128-bit Session Keys ........................... 4
+ 2.4. Key Derivation Functions .................................. 5
+ 2.5. Sample Key Derivations .................................... 6
+ 2.5.1. Sample 40-bit Key Derivation ............................ 6
+ 2.5.2. Sample 56-bit Key Derivation ............................ 6
+ 2.5.3. Sample 128-bit Key Derivation ........................... 7
+ 3. Deriving Session Keys from MS-CHAP-2 Credentials ............ 7
+ 3.1. Generating 40-bit Session Keys ............................ 8
+ 3.2. Generating 56-bit Session Keys ............................ 9
+ 3.3. Generating 128-bit Session Keys ...........................10
+ 3.4. Key Derivation Functions ..................................11
+ 3.5. Sample Key Derivations ....................................13
+ 3.5.1. Sample 40-bit Key Derivation ............................13
+ 3.5.2. Sample 56-bit Key Derivation ............................14
+ 3.5.3. Sample 128-bit Key Derivation ...........................15
+ 4. Deriving MPPE Session Keys from TLS Session Keys ............16
+ 4.1. Generating 40-bit Session Keys ............................16
+ 4.2. Generating 56-bit Session Keys ............................17
+ 4.3. Generating 128-bit Session Keys ...........................17
+ 5. Security Considerations .....................................18
+ 5.1. MS-CHAP Credentials .......................................18
+ 5.2. EAP-TLS Credentials .......................................19
+ 6. References ..................................................19
+ 7. Acknowledgements ............................................20
+ 8. Author's Address ............................................20
+ 9. Full Copyright Statement ....................................21
+
+1. 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 [6].
+
+2. Deriving Session Keys from MS-CHAP Credentials
+
+ The Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP-1)
+ [2] is a Microsoft-proprietary PPP [1] authentication protocol,
+ providing the functionality to which LAN-based users are accustomed
+ while integrating the encryption and hashing algorithms used on
+ Windows networks.
+
+
+
+
+
+Zorn Informational [Page 2]
+
+RFC 3079 MPPE Key Derivation March 2001
+
+
+ The following sections detail the methods used to derive initial
+ session keys (40-, 56- and 128-bit) from MS-CHAP-1 credentials.
+
+ Implementation Note
+
+ The initial session key in both directions is derived from the
+ credentials of the peer that initiated the call and the challenge
+ used (if any) is the challenge from the first authentication.
+ This is true for both unilateral and bilateral authentication, as
+ well as for each link in a multilink bundle. In the multi-chassis
+ multilink case, implementations are responsible for ensuring that
+ the correct keys are generated on all participating machines.
+
+2.1. Generating 40-bit Session Keys
+
+ MPPE uses a derivative of the peer's LAN Manager password as the 40-
+ bit session key used for initializing the RC4 encryption tables.
+
+ The first step is to obfuscate the peer's password using the
+ LmPasswordHash() function (described in [2]). The first 8 octets of
+ the result are used as the basis for the session key generated in the
+ following way:
+
+/*
+* PasswordHash is the basis for the session key
+* SessionKey is a copy of PasswordHash and is the generative session key
+* 8 is the length (in octets) of the key to be generated.
+*
+*/
+Get_Key(PasswordHash, SessionKey, 8)
+
+/*
+* The effective length of the key is reduced to 40 bits by
+* replacing the first three bytes as follows:
+*/
+SessionKey[0] = 0xd1 ;
+SessionKey[1] = 0x26 ;
+SessionKey[2] = 0x9e ;
+
+2.2. Generating 56-bit Session Keys
+
+ MPPE uses a derivative of the peer's LAN Manager password as the 56-
+ bit session key used for initializing the RC4 encryption tables.
+
+ The first step is to obfuscate the peer's password using the
+ LmPasswordHash() function (described in [2]). The first 8 octets of
+ the result are used as the basis for the session key generated in the
+ following way:
+
+
+
+Zorn Informational [Page 3]
+
+RFC 3079 MPPE Key Derivation March 2001
+
+
+/*
+* PasswordHash is the basis for the session key
+* SessionKey is a copy of PasswordHash and is the generative session key
+* 8 is the length (in octets) of the key to be generated.
+*
+*/
+Get_Key(PasswordHash, SessionKey, 8)
+
+/*
+* The effective length of the key is reduced to 56 bits by
+* replacing the first byte as follows:
+*/
+SessionKey[0] = 0xd1 ;
+
+2.3. Generating 128-bit Session Keys
+
+ MPPE uses a derivative of the peer's Windows NT password as the 128-
+ bit session key used for initializing encryption tables.
+
+ The first step is to obfuscate the peer's password using
+ NtPasswordHash() function as described in [2]. The first 16 octets
+ of the result are then hashed again using the MD4 algorithm. The
+ first 16 octets of the second hash are used as the basis for the
+ session key generated in the following way:
+
+/*
+* Challenge (as described in [9]) is sent by the PPP authenticator
+* during authentication and is 8 octets long.
+* NtPasswordHashHash is the basis for the session key.
+* On return, InitialSessionKey contains the initial session
+* key to be used.
+*/
+Get_Start_Key(Challenge, NtPasswordHashHash, InitialSessionKey)
+
+/*
+* CurrentSessionKey is a copy of InitialSessionKey
+* and is the generative session key.
+* Length (in octets) of the key to generate is 16.
+*
+*/
+Get_Key(InitialSessionKey, CurrentSessionKey, 16)
+
+
+
+
+
+
+
+
+
+
+Zorn Informational [Page 4]
+
+RFC 3079 MPPE Key Derivation March 2001
+
+
+2.4. Key Derivation Functions
+
+ The following procedures are used to derive the session key.
+
+/*
+ * Pads used in key derivation
+ */
+
+SHApad1[40] =
+ {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
+
+SHApad2[40] =
+ {0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2,
+ 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2,
+ 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2,
+ 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2};
+
+/*
+ * SHAInit(), SHAUpdate() and SHAFinal() functions are an
+ * implementation of Secure Hash Algorithm (SHA-1) [7]. These are
+ * available in public domain or can be licensed from
+ * RSA Data Security, Inc.
+ *
+ * 1) InitialSessionKey is 8 octets long for 56- and 40-bit
+ * session keys, 16 octets long for 128 bit session keys.
+ * 2) CurrentSessionKey is same as InitialSessionKey when this
+ * routine is called for the first time for the session.
+ */
+
+Get_Key(
+IN InitialSessionKey,
+IN/OUT CurrentSessionKey
+IN LengthOfDesiredKey )
+{
+ SHAInit(Context)
+ SHAUpdate(Context, InitialSessionKey, LengthOfDesiredKey)
+ SHAUpdate(Context, SHAPad1, 40)
+ SHAUpdate(Context, CurrentSessionKey, LengthOfDesiredKey)
+ SHAUpdate(Context, SHAPad2, 40)
+ SHAFinal(Context, Digest)
+ memcpy(CurrentSessionKey, Digest, LengthOfDesiredKey)
+}
+
+Get_Start_Key(
+IN Challenge,
+
+
+
+Zorn Informational [Page 5]
+
+RFC 3079 MPPE Key Derivation March 2001
+
+
+IN NtPasswordHashHash,
+OUT InitialSessionKey)
+{
+ SHAInit(Context)
+ SHAUpdate(Context, NtPasswordHashHash, 16)
+ SHAUpdate(Context, NtPasswordHashHash, 16)
+ SHAUpdate(Context, Challenge, 8)
+ SHAFinal(Context, Digest)
+ memcpy(InitialSessionKey, Digest, 16)
+}
+
+2.5. Sample Key Derivations
+
+ The following sections illustrate 40-, 56- and 128-bit key
+ derivations. All intermediate values are in hexadecimal.
+
+2.5.1. Sample 40-bit Key Derivation
+
+
+ Initial Values
+ Password = "clientPass"
+
+ Step 1: LmPasswordHash(Password, PasswordHash)
+ PasswordHash = 76 a1 52 93 60 96 d7 83 0e 23 90 22 74 04 af d2
+
+ Step 2: Copy PasswordHash to SessionKey
+ SessionKey = 76 a1 52 93 60 96 d7 83 0e 23 90 22 74 04 af d2
+
+ Step 3: GetKey(PasswordHash, SessionKey, 8)
+ SessionKey = d8 08 01 53 8c ec 4a 08
+
+ Step 4: Reduce the effective key length to 40 bits
+ SessionKey = d1 26 9e 53 8c ec 4a 08
+
+2.5.2. Sample 56-bit Key Derivation
+
+ Initial Values
+ Password = "clientPass"
+
+ Step 1: LmPasswordHash(Password, PasswordHash)
+ PasswordHash = 76 a1 52 93 60 96 d7 83 0e 23 90 22 74 04 af d2
+
+ Step 2: Copy PasswordHash to SessionKey
+ SessionKey = 76 a1 52 93 60 96 d7 83 0e 23 90 22 74 04 af d2
+
+ Step 3: GetKey(PasswordHash, SessionKey, 8)
+ SessionKey = d8 08 01 53 8c ec 4a 08
+
+
+
+
+Zorn Informational [Page 6]
+
+RFC 3079 MPPE Key Derivation March 2001
+
+
+ Step 4: Reduce the effective key length to 56 bits
+ SessionKey = d1 08 01 53 8c ec 4a 08
+
+2.5.3. Sample 128-bit Key Derivation
+
+Initial Values
+ Password = "clientPass"
+ Challenge = 10 2d b5 df 08 5d 30 41
+
+Step 1: NtPasswordHash(Password, PasswordHash)
+ PasswordHash = 44 eb ba 8d 53 12 b8 d6 11 47 44 11 f5 69 89 ae
+
+Step 2: PasswordHashHash = MD4(PasswordHash)
+ PasswordHashHash = 41 c0 0c 58 4b d2 d9 1c 40 17 a2 a1 2f a5 9f 3f
+
+Step 3: GetStartKey(Challenge, PasswordHashHash, InitialSessionKey)
+ InitialSessionKey = a8 94 78 50 cf c0 ac ca d1 78 9f b6 2d dc dd b0
+
+Step 4: Copy InitialSessionKey to CurrentSessionKey
+ CurrentSessionKey = a8 94 78 50 cf c0 ac c1 d1 78 9f b6 2d dc dd b0
+
+Step 5: GetKey(InitialSessionKey, CurrentSessionKey, 16)
+ CurrentSessionKey = 59 d1 59 bc 09 f7 6f 1d a2 a8 6a 28 ff ec 0b 1e
+
+3. Deriving Session Keys from MS-CHAP-2 Credentials
+
+ Version 2 of the Microsoft Challenge-Handshake Authentication
+ Protocol (MS-CHAP-2) [8] is a Microsoft-proprietary PPP
+ authentication protocol, providing the functionality to which LAN-
+ based users are accustomed while integrating the encryption and
+ hashing algorithms used on Windows networks.
+
+ The following sections detail the methods used to derive initial
+ session keys from MS-CHAP-2 credentials. 40-, 56- and 128-bit keys
+ are all derived using the same algorithm from the authenticating
+ peer's Windows NT password. The only difference is in the length of
+ the keys and their effective strength: 40- and 56-bit keys are 8
+ octets in length, while 128-bit keys are 16 octets long. Separate
+ keys are derived for the send and receive directions of the session.
+
+ Implementation Note
+
+ The initial session keys in both directions are derived from the
+ credentials of the peer that initiated the call and the challenges
+ used are those from the first authentication. This is true as
+ well for each link in a multilink bundle. In the multi-chassis
+ multilink case, implementations are responsible for ensuring that
+ the correct keys are generated on all participating machines.
+
+
+
+Zorn Informational [Page 7]
+
+RFC 3079 MPPE Key Derivation March 2001
+
+
+3.1. Generating 40-bit Session Keys
+
+ When used in conjunction with MS-CHAP-2 authentication, the initial
+ MPPE session keys are derived from the peer's Windows NT password.
+
+ The first step is to obfuscate the peer's password using
+ NtPasswordHash() function as described in [8].
+
+ NtPasswordHash(Password, PasswordHash)
+
+ The first 16 octets of the result are then hashed again using the MD4
+ algorithm.
+
+ PasswordHashHash = md4(PasswordHash)
+
+ The first 16 octets of this second hash are used together with the
+ NT- Response field from the MS-CHAP-2 Response packet [8] as the
+ basis for the master session key:
+
+ GetMasterKey(PasswordHashHash, NtResponse, MasterKey)
+
+ Once the master key has been generated, it is used to derive two 40-
+ bit session keys, one for sending and one for receiving:
+
+ GetAsymmetricStartKey(MasterKey, MasterSendKey, 8, TRUE, TRUE)
+ GetAsymmetricStartKey(MasterKey, MasterReceiveKey, 8, FALSE, TRUE)
+
+ The master session keys are never used to encrypt or decrypt data;
+ they are only used in the derivation of transient session keys. The
+ initial transient session keys are obtained by calling the function
+ GetNewKeyFromSHA() (described in [3]):
+
+GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 8, SendSessionKey)
+GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 8,
+ ReceiveSessionKey)
+
+ Next, the effective strength of both keys is reduced by setting the
+ first three octets to known constants:
+
+ SendSessionKey[0] = ReceiveSessionKey[0] = 0xd1
+ SendSessionKey[1] = ReceiveSessionKey[1] = 0x26
+ SendSessionKey[2] = ReceiveSessionKey[2] = 0x9e
+
+ Finally, the RC4 tables are initialized using the new session keys:
+
+ rc4_key(SendRC4key, 8, SendSessionKey)
+ rc4_key(ReceiveRC4key, 8, ReceiveSessionKey)
+
+
+
+
+Zorn Informational [Page 8]
+
+RFC 3079 MPPE Key Derivation March 2001
+
+
+3.2. Generating 56-bit Session Keys
+
+ When used in conjunction with MS-CHAP-2 authentication, the initial
+ MPPE session keys are derived from the peer's Windows NT password.
+
+ The first step is to obfuscate the peer's password using
+ NtPasswordHash() function as described in [8].
+
+ NtPasswordHash(Password, PasswordHash)
+
+ The first 16 octets of the result are then hashed again using the MD4
+ algorithm.
+
+ PasswordHashHash = md4(PasswordHash)
+
+ The first 16 octets of this second hash are used together with the
+ NT-Response field from the MS-CHAP-2 Response packet [8] as the basis
+ for the master session key:
+
+ GetMasterKey(PasswordHashHash, NtResponse, MasterKey)
+
+ Once the master key has been generated, it is used to derive two
+ 56-bit session keys, one for sending and one for receiving:
+
+ GetAsymmetricStartKey(MasterKey, MasterSendKey, 8, TRUE, TRUE)
+ GetAsymmetricStartKey(MasterKey, MasterReceiveKey, 8, FALSE, TRUE)
+
+ The master session keys are never used to encrypt or decrypt data;
+ they are only used in the derivation of transient session keys. The
+ initial transient session keys are obtained by calling the function
+ GetNewKeyFromSHA() (described in [3]):
+
+GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 8, SendSessionKey)
+GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 8,
+ ReceiveSessionKey)
+
+ Next, the effective strength of both keys is reduced by setting the
+ first octet to a known constant:
+
+ SendSessionKey[0] = ReceiveSessionKey[0] = 0xd1
+
+ Finally, the RC4 tables are initialized using the new session keys:
+
+ rc4_key(SendRC4key, 8, SendSessionKey)
+ rc4_key(ReceiveRC4key, 8, ReceiveSessionKey)
+
+
+
+
+
+
+Zorn Informational [Page 9]
+
+RFC 3079 MPPE Key Derivation March 2001
+
+
+3.3. Generating 128-bit Session Keys
+
+ When used in conjunction with MS-CHAP-2 authentication, the initial
+ MPPE session keys are derived from the peer's Windows NT password.
+
+ The first step is to obfuscate the peer's password using
+ NtPasswordHash() function as described in [8].
+
+ NtPasswordHash(Password, PasswordHash)
+
+ The first 16 octets of the result are then hashed again using the MD4
+ algorithm.
+
+ PasswordHashHash = md4(PasswordHash)
+
+ The first 16 octets of this second hash are used together with the
+ NT-Response field from the MS-CHAP-2 Response packet [8] as the basis
+ for the master session key:
+
+ GetMasterKey(PasswordHashHash, NtResponse, MasterKey)
+
+ Once the master key has been generated, it is used to derive two
+ 128-bit master session keys, one for sending and one for receiving:
+
+GetAsymmetricStartKey(MasterKey, MasterSendKey, 16, TRUE, TRUE)
+GetAsymmetricStartKey(MasterKey, MasterReceiveKey, 16, FALSE, TRUE)
+
+ The master session keys are never used to encrypt or decrypt data;
+ they are only used in the derivation of transient session keys. The
+ initial transient session keys are obtained by calling the function
+ GetNewKeyFromSHA() (described in [3]):
+
+GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 16, SendSessionKey)
+GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 16,
+ ReceiveSessionKey)
+
+ Finally, the RC4 tables are initialized using the new session keys:
+
+ rc4_key(SendRC4key, 16, SendSessionKey)
+ rc4_key(ReceiveRC4key, 16, ReceiveSessionKey)
+
+
+
+
+
+
+
+
+
+
+
+Zorn Informational [Page 10]
+
+RFC 3079 MPPE Key Derivation March 2001
+
+
+3.4. Key Derivation Functions
+
+ The following procedures are used to derive the session key.
+
+/*
+ * Pads used in key derivation
+ */
+
+SHSpad1[40] =
+ {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
+
+SHSpad2[40] =
+ {0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2,
+ 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2,
+ 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2,
+ 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2};
+
+/*
+ * "Magic" constants used in key derivations
+ */
+
+Magic1[27] =
+ {0x54, 0x68, 0x69, 0x73, 0x20, 0x69, 0x73, 0x20, 0x74,
+ 0x68, 0x65, 0x20, 0x4d, 0x50, 0x50, 0x45, 0x20, 0x4d,
+ 0x61, 0x73, 0x74, 0x65, 0x72, 0x20, 0x4b, 0x65, 0x79};
+
+Magic2[84] =
+ {0x4f, 0x6e, 0x20, 0x74, 0x68, 0x65, 0x20, 0x63, 0x6c, 0x69,
+ 0x65, 0x6e, 0x74, 0x20, 0x73, 0x69, 0x64, 0x65, 0x2c, 0x20,
+ 0x74, 0x68, 0x69, 0x73, 0x20, 0x69, 0x73, 0x20, 0x74, 0x68,
+ 0x65, 0x20, 0x73, 0x65, 0x6e, 0x64, 0x20, 0x6b, 0x65, 0x79,
+ 0x3b, 0x20, 0x6f, 0x6e, 0x20, 0x74, 0x68, 0x65, 0x20, 0x73,
+ 0x65, 0x72, 0x76, 0x65, 0x72, 0x20, 0x73, 0x69, 0x64, 0x65,
+ 0x2c, 0x20, 0x69, 0x74, 0x20, 0x69, 0x73, 0x20, 0x74, 0x68,
+ 0x65, 0x20, 0x72, 0x65, 0x63, 0x65, 0x69, 0x76, 0x65, 0x20,
+ 0x6b, 0x65, 0x79, 0x2e};
+
+Magic3[84] =
+ {0x4f, 0x6e, 0x20, 0x74, 0x68, 0x65, 0x20, 0x63, 0x6c, 0x69,
+ 0x65, 0x6e, 0x74, 0x20, 0x73, 0x69, 0x64, 0x65, 0x2c, 0x20,
+ 0x74, 0x68, 0x69, 0x73, 0x20, 0x69, 0x73, 0x20, 0x74, 0x68,
+ 0x65, 0x20, 0x72, 0x65, 0x63, 0x65, 0x69, 0x76, 0x65, 0x20,
+ 0x6b, 0x65, 0x79, 0x3b, 0x20, 0x6f, 0x6e, 0x20, 0x74, 0x68,
+ 0x65, 0x20, 0x73, 0x65, 0x72, 0x76, 0x65, 0x72, 0x20, 0x73,
+ 0x69, 0x64, 0x65, 0x2c, 0x20, 0x69, 0x74, 0x20, 0x69, 0x73,
+
+
+
+Zorn Informational [Page 11]
+
+RFC 3079 MPPE Key Derivation March 2001
+
+
+ 0x20, 0x74, 0x68, 0x65, 0x20, 0x73, 0x65, 0x6e, 0x64, 0x20,
+ 0x6b, 0x65, 0x79, 0x2e};
+
+
+ GetMasterKey(
+ IN 16-octet PasswordHashHash,
+ IN 24-octet NTResponse,
+ OUT 16-octet MasterKey )
+ {
+ 20-octet Digest
+
+ ZeroMemory(Digest, sizeof(Digest));
+
+ /*
+ * SHSInit(), SHSUpdate() and SHSFinal()
+ * are an implementation of the Secure Hash Standard [7].
+ */
+
+ SHSInit(Context);
+ SHSUpdate(Context, PasswordHashHash, 16);
+ SHSUpdate(Context, NTResponse, 24);
+ SHSUpdate(Context, Magic1, 27);
+ SHSFinal(Context, Digest);
+
+ MoveMemory(MasterKey, Digest, 16);
+ }
+
+ VOID
+ GetAsymetricStartKey(
+ IN 16-octet MasterKey,
+ OUT 8-to-16 octet SessionKey,
+ IN INTEGER SessionKeyLength,
+ IN BOOLEAN IsSend,
+ IN BOOLEAN IsServer )
+ {
+
+ 20-octet Digest;
+
+ ZeroMemory(Digest, 20);
+
+ if (IsSend) {
+ if (IsServer) {
+ s = Magic3
+ } else {
+ s = Magic2
+ }
+ } else {
+ if (IsServer) {
+
+
+
+Zorn Informational [Page 12]
+
+RFC 3079 MPPE Key Derivation March 2001
+
+
+ s = Magic2
+ } else {
+ s = Magic3
+ }
+ }
+
+ /*
+ * SHSInit(), SHSUpdate() and SHSFinal()
+ * are an implementation of the Secure Hash Standard [7].
+ */
+
+ SHSInit(Context);
+ SHSUpdate(Context, MasterKey, 16);
+ SHSUpdate(Context, SHSpad1, 40);
+ SHSUpdate(Context, s, 84);
+ SHSUpdate(Context, SHSpad2, 40);
+ SHSFinal(Context, Digest);
+
+ MoveMemory(SessionKey, Digest, SessionKeyLength);
+ }
+
+3.5. Sample Key Derivations
+
+ The following sections illustrate 40-, 56- and 128-bit key
+ derivations. All intermediate values are in hexadecimal.
+
+3.5.1. Sample 40-bit Key Derivation
+
+Initial Values
+ UserName = "User"
+ = 55 73 65 72
+
+ Password = "clientPass"
+ = 63 00 6C 00 69 00 65 00 6E 00
+ 74 00 50 00 61 00 73 00 73 00
+
+ AuthenticatorChallenge = 5B 5D 7C 7D 7B 3F 2F 3E 3C 2C
+ 60 21 32 26 26 28
+ PeerChallenge = 21 40 23 24 25 5E 26 2A 28 29 5F 2B 3A 33 7C 7E
+
+ Challenge = D0 2E 43 86 BC E9 12 26
+
+ 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
+
+Step 1: NtPasswordHash(Password, PasswordHash)
+ PasswordHash = 44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE
+
+
+
+Zorn Informational [Page 13]
+
+RFC 3079 MPPE Key Derivation March 2001
+
+
+Step 2: PasswordHashHash = MD4(PasswordHash)
+ PasswordHashHash = 41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F
+
+Step 3: Derive the master key (GetMasterKey())
+ MasterKey = FD EC E3 71 7A 8C 83 8C B3 88 E5 27 AE 3C DD 31
+
+Step 4: Derive the master send session key (GetAsymmetricStartKey())
+ SendStartKey40 = 8B 7C DC 14 9B 99 3A 1B
+
+Step 5: Derive the initial send session key (GetNewKeyFromSHA())
+ SendSessionKey40 = D1 26 9E C4 9F A6 2E 3E
+
+Sample Encrypted Message
+ rc4(SendSessionKey40, "test message") = 92 91 37 91 7E 58 03 D6
+ 68 D7 58 98
+
+3.5.2. Sample 56-bit Key Derivation
+
+Initial Values
+ UserName = "User"
+ = 55 73 65 72
+
+ Password = "clientPass"
+ = 63 00 6C 00 69 00 65 00 6E 00 74 00 50
+ 00 61 00 73 00 73 00
+
+ AuthenticatorChallenge = 5B 5D 7C 7D 7B 3F 2F 3E 3C 2C
+ 60 21 32 26 26 28
+ PeerChallenge = 21 40 23 24 25 5E 26 2A 28 29 5F 2B 3A 33 7C 7E
+
+ Challenge = D0 2E 43 86 BC E9 12 26
+
+ 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
+
+Step 1: NtPasswordHash(Password, PasswordHash)
+ PasswordHash = 44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE
+
+Step 2: PasswordHashHash = MD4(PasswordHash)
+ PasswordHashHash = 41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F
+
+Step 3: Derive the master key (GetMasterKey())
+ MasterKey = FD EC E3 71 7A 8C 83 8C B3 88 E5 27 AE 3C DD 31
+
+Step 4: Derive the master send session key (GetAsymmetricStartKey())
+ SendStartKey56 = 8B 7C DC 14 9B 99 3A 1B
+
+
+
+
+Zorn Informational [Page 14]
+
+RFC 3079 MPPE Key Derivation March 2001
+
+
+Step 5: Derive the initial send session key (GetNewKeyFromSHA())
+ SendSessionKey56 = D1 5C 00 C4 9F A6 2E 3E
+
+Sample Encrypted Message
+ rc4(SendSessionKey40, "test message") = 3F 10 68 33 FA 44 8D
+ A8 42 BC 57 58
+
+3.5.3. Sample 128-bit Key Derivation
+
+Initial Values
+ UserName = "User"
+ = 55 73 65 72
+
+ Password = "clientPass"
+ = 63 00 6C 00 69 00 65 00 6E 00
+ 74 00 50 00 61 00 73 00 73 00
+
+ AuthenticatorChallenge = 5B 5D 7C 7D 7B 3F 2F 3E 3C 2C
+ 60 21 32 26 26 28
+
+ PeerChallenge = 21 40 23 24 25 5E 26 2A 28 29 5F 2B 3A 33 7C 7E
+
+ Challenge = D0 2E 43 86 BC E9 12 26
+
+ 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
+
+Step 1: NtPasswordHash(Password, PasswordHash)
+ PasswordHash = 44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE
+
+Step 2: PasswordHashHash = MD4(PasswordHash)
+ PasswordHashHash = 41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F
+
+Step 2: Derive the master key (GetMasterKey())
+ MasterKey = FD EC E3 71 7A 8C 83 8C B3 88 E5 27 AE 3C DD 31
+
+Step 3: Derive the send master session key (GetAsymmetricStartKey())
+
+ SendStartKey128 = 8B 7C DC 14 9B 99 3A 1B A1 18 CB 15 3F 56 DC CB
+
+Step 4: Derive the initial send session key (GetNewKeyFromSHA())
+ SendSessionKey128 = 40 5C B2 24 7A 79 56 E6 E2 11 00 7A E2 7B 22 D4
+
+Sample Encrypted Message
+ rc4(SendSessionKey128, "test message") = 81 84 83 17 DF 68
+ 84 62 72 FB 5A BE
+
+
+
+
+Zorn Informational [Page 15]
+
+RFC 3079 MPPE Key Derivation March 2001
+
+
+4. Deriving MPPE Session Keys from TLS Session Keys
+
+ The Extensible Authentication Protocol (EAP) [10] is a PPP extension
+ that provides support for additional authentication methods within
+ PPP. Transport Level Security (TLS) [11] provides for mutual
+ authentication, integrity-protected ciphersuite negotiation and key
+ exchange between two endpoints. EAP-TLS [12] is an EAP
+ authentication type which allows the use of TLS within the PPP
+ authentication framework. The following sections describe the
+ methods used to derive initial session keys from TLS session keys.
+ 56-, 40- and 128-bit keys are derived using the same algorithm. The
+ only difference is in the length of the keys and their effective
+ strength: 56- and 40-bit keys are 8 octets in length, while 128-bit
+ keys are 16 octets long. Separate keys are derived for the send and
+ receive directions of the session.
+
+4.1. Generating 40-bit Session Keys
+
+ When MPPE is used in conjunction with EAP-TLS authentication, the TLS
+ master secret is used as the master session key.
+
+ The algorithm used to derive asymmetrical master session keys from
+ the TLS master secret is described in [12]. The master session keys
+ are never used to encrypt or decrypt data; they are only used in the
+ derivation of transient session keys.
+
+ Implementation Note
+
+ If the asymmetrical master keys are less than 8 octets in length,
+ they MUST be padded on the left with zeroes before being used to
+ derive the initial transient session keys. Conversely, if the
+ asymmetrical master keys are more than 8 octets in length, they
+ must be truncated to 8 octets before being used to derive the
+ initial transient session keys.
+
+ The initial transient session keys are obtained by calling the
+ function GetNewKeyFromSHA() (described in [3]):
+
+GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 8, SendSessionKey)
+GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 8,
+ReceiveSessionKey)
+
+ Next, the effective strength of both keys is reduced by setting the
+ first three octets to known constants:
+
+ SendSessionKey[0] = ReceiveSessionKey[0] = 0xD1
+ SendSessionKey[1] = ReceiveSessionKey[1] = 0x26
+ SendSessionKey[2] = ReceiveSessionKey[2] = 0x9E
+
+
+
+Zorn Informational [Page 16]
+
+RFC 3079 MPPE Key Derivation March 2001
+
+
+ Finally, the RC4 tables are initialized using the new session keys:
+
+ rc4_key(SendRC4key, 8, SendSessionKey)
+ rc4_key(ReceiveRC4key, 8, ReceiveSessionKey)
+
+4.2. Generating 56-bit Session Keys
+
+ When MPPE is used in conjunction with EAP-TLS authentication, the TLS
+ master secret is used as the master session key.
+
+ The algorithm used to derive asymmetrical master session keys from
+ the TLS master secret is described in [12]. The master session keys
+ are never used to encrypt or decrypt data; they are only used in the
+ derivation of transient session keys.
+
+ Implementation Note
+
+ If the asymmetrical master keys are less than 8 octets in length,
+ they MUST be padded on the left with zeroes before being used to
+ derive the initial transient session keys. Conversely, if the
+ asymmetrical master keys are more than 8 octets in length, they
+ must be truncated to 8 octets before being used to derive the
+ initial transient session keys.
+
+ The initial transient session keys are obtained by calling the
+ function GetNewKeyFromSHA() (described in [3]):
+
+GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 8, SendSessionKey)
+GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 8,
+ReceiveSessionKey)
+
+ Next, the effective strength of both keys is reduced by setting the
+ initial octet to a known constant:
+
+ SendSessionKey[0] = ReceiveSessionKey[0] = 0xD1
+
+ Finally, the RC4 tables are initialized using the new session keys:
+
+ rc4_key(SendRC4key, 8, SendSessionKey)
+ rc4_key(ReceiveRC4key, 8, ReceiveSessionKey)
+
+4.3. Generating 128-bit Session Keys
+
+ When MPPE is used in conjunction with EAP-TLS authentication, the TLS
+ master secret is used as the master session key.
+
+
+
+
+
+
+Zorn Informational [Page 17]
+
+RFC 3079 MPPE Key Derivation March 2001
+
+
+ The algorithm used to derive asymmetrical master session keys from
+ the TLS master secret is described in [12]. Note that the send key
+ on one side is the receive key on the other.
+
+ The master session keys are never used to encrypt or decrypt data;
+ they are only used in the derivation of transient session keys.
+
+ Implementation Note
+
+ If the asymmetrical master keys are less than 16 octets in length,
+ they MUST be padded on the left with zeroes before being used to
+ derive the initial transient session keys. Conversely, if the
+ asymmetrical master keys are more than 16 octets in length, they
+ must be truncated to 16 octets before being used to derive the
+ initial transient session keys.
+
+ The initial transient session keys are obtained by calling the
+ function GetNewKeyFromSHA() (described in [3]):
+
+GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 16, SendSessionKey)
+GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 16,
+ReceiveSessionKey)
+
+ Finally, the RC4 tables are initialized using the new session keys:
+
+ rc4_key(SendRC4key, 16, SendSessionKey)
+ rc4_key(ReceiveRC4key, 16, ReceiveSessionKey)
+
+5. Security Considerations
+
+5.1. MS-CHAP Credentials
+
+ Because of the way in which 40-bit keys are derived from MS-CHAP-1
+ credentials, the initial 40-bit session key will be identical in all
+ sessions established under the same peer credentials. For this
+ reason, and because RC4 with a 40-bit key length is believed to be a
+ relatively weak cipher, peers SHOULD NOT use 40-bit keys derived from
+ the LAN Manager password hash (as described above) if it can be
+ avoided.
+
+ Since the MPPE session keys are derived from user passwords (in the
+ MS- CHAP-1 and MS-CHAP-2 cases), care should be taken to ensure the
+ selection of strong passwords and passwords should be changed
+ frequently.
+
+
+
+
+
+
+
+Zorn Informational [Page 18]
+
+RFC 3079 MPPE Key Derivation March 2001
+
+
+5.2. EAP-TLS Credentials
+
+ The strength of the session keys is dependent upon the security of
+ the TLS protocol.
+
+ The EAP server may be on a separate machine from the PPP
+ authenticator; if this is the case, adequate care must be taken in
+ the transmission of the EAP-TLS master keys to the authenticator.
+
+6. References
+
+ [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
+ 1661, July 1994.
+
+ [2] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 2433,
+ October 1998.
+
+ [3] Pall, G. and G. Zorn, "Microsoft Point-to-Point Encryption
+ (MPPE) RFC 3078, March 2001.
+
+ [4] 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
+
+ [5] Pall, G., "Microsoft Point-to-Point Compression (MPPC)
+ Protocol", RFC 2118, March 1997.
+
+ [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [7] "Secure Hash Standard", Federal Information Processing Standards
+ Publication 180-1, National Institute of Standards and
+ Technology, April 1995.
+
+ [8] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 2759,
+ January 2000.
+
+ [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.
+
+
+
+
+
+
+Zorn Informational [Page 19]
+
+RFC 3079 MPPE Key Derivation March 2001
+
+
+ [11] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
+ 2246, January 1999.
+
+ [12] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol",
+ RFC 2716, October 1999.
+
+7. 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, Vijay Baliga, Brad Robel-Forrest and Jeff Haag
+ for useful feedback.
+
+ The technical portions of this memo were completed while the author
+ was employed by Microsoft Corporation.
+
+8. Author's Address
+
+ Questions about this memo can also be directed to:
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zorn Informational [Page 20]
+
+RFC 3079 MPPE Key Derivation March 2001
+
+
+9. 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zorn Informational [Page 21]
+
diff --git a/rfc/rfc3544.txt b/rfc/rfc3544.txt
new file mode 100644
index 0000000..b4d2ac5
--- /dev/null
+++ b/rfc/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]
+
diff --git a/rfc/rfc3576.txt b/rfc/rfc3576.txt
new file mode 100644
index 0000000..89fd9eb
--- /dev/null
+++ b/rfc/rfc3576.txt
@@ -0,0 +1,1683 @@
+
+
+
+
+
+
+Network Working Group M. Chiba
+Request for Comments: 3576 G. Dommety
+Category: Informational M. Eklund
+ Cisco Systems, Inc.
+ D. Mitton
+ Circular Logic, UnLtd.
+ B. Aboba
+ Microsoft Corporation
+ July 2003
+
+
+ Dynamic Authorization Extensions to Remote
+ Authentication Dial In User Service (RADIUS)
+
+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 (2003). All Rights Reserved.
+
+Abstract
+
+ This document describes a currently deployed extension to the Remote
+ Authentication Dial In User Service (RADIUS) protocol, allowing
+ dynamic changes to a user session, as implemented by network access
+ server products. This includes support for disconnecting users and
+ changing authorizations applicable to a user session.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chiba, et al. Informational [Page 1]
+
+RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. Applicability. . . . . . . . . . . . . . . . . . . . . . 3
+ 1.2. Requirements Language . . . . . . . . . . . . . . . . . 5
+ 1.3. Terminology. . . . . . . . . . . . . . . . . . . . . . . 5
+ 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 2.1. Disconnect Messages (DM) . . . . . . . . . . . . . . . . 5
+ 2.2. Change-of-Authorization Messages (CoA) . . . . . . . . . 6
+ 2.3. Packet Format. . . . . . . . . . . . . . . . . . . . . . 7
+ 3. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 3.1. Error-Cause. . . . . . . . . . . . . . . . . . . . . . . 13
+ 3.2. Table of Attributes. . . . . . . . . . . . . . . . . . . 16
+ 4. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 20
+ 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 21
+ 5.1. Authorization Issues . . . . . . . . . . . . . . . . . . 21
+ 5.2. Impersonation. . . . . . . . . . . . . . . . . . . . . . 22
+ 5.3. IPsec Usage Guidelines . . . . . . . . . . . . . . . . . 22
+ 5.4. Replay Protection. . . . . . . . . . . . . . . . . . . . 25
+ 6. Example Traces . . . . . . . . . . . . . . . . . . . . . . . . 26
+ 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
+ 7.1. Normative References . . . . . . . . . . . . . . . . . . 26
+ 7.2. Informative References . . . . . . . . . . . . . . . . . 27
+ 8. Intellectual Property Statement. . . . . . . . . . . . . . . . 28
+ 9. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 28
+ 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29
+ 11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 30
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chiba, et al. Informational [Page 2]
+
+RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
+
+
+1. Introduction
+
+ The RADIUS protocol, defined in [RFC2865], does not support
+ unsolicited messages sent from the RADIUS server to the Network
+ Access Server (NAS).
+
+ However, there are many instances in which it is desirable for
+ changes to be made to session characteristics, without requiring the
+ NAS to initiate the exchange. For example, it may be desirable for
+ administrators to be able to terminate a user session in progress.
+ Alternatively, if the user changes authorization level, this may
+ require that authorization attributes be added/deleted from a user
+ session.
+
+ To overcome these limitations, several vendors have implemented
+ additional RADIUS commands in order to be able to support unsolicited
+ messages sent from the RADIUS server to the NAS. These extended
+ commands provide support for Disconnect and Change-of-Authorization
+ (CoA) messages. Disconnect messages cause a user session to be
+ terminated immediately, whereas CoA messages modify session
+ authorization attributes such as data filters.
+
+1.1. Applicability
+
+ This protocol is being recommended for publication as an
+ Informational RFC rather than as a standards-track RFC because of
+ problems that cannot be fixed without creating incompatibilities with
+ deployed implementations. This includes security vulnerabilities, as
+ well as semantic ambiguities resulting from the design of the
+ Change-of-Authorization (CoA) commands. While fixes are recommended,
+ they cannot be made mandatory since this would be incompatible with
+ existing implementations.
+
+ Existing implementations of this protocol do not support
+ authorization checks, so that an ISP sharing a NAS with another ISP
+ could disconnect or change authorizations for another ISP's users.
+ In order to remedy this problem, a "Reverse Path Forwarding" check is
+ recommended. See Section 5.1. for details.
+
+ Existing implementations utilize per-packet authentication and
+ integrity protection algorithms with known weaknesses [MD5Attack].
+ To provide stronger per-packet authentication and integrity
+ protection, the use of IPsec is recommended. See Section 5.3. for
+ details.
+
+
+
+
+
+
+
+Chiba, et al. Informational [Page 3]
+
+RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
+
+
+ Existing implementations lack replay protection. In order to support
+ replay detection, it is recommended that the Event-Timestamp
+ Attribute be added to all messages in situations where IPsec replay
+ protection is not employed. Implementations should be configurable
+ to silently discard messages lacking the Event-Timestamp Attribute.
+ See Section 5.4. for details.
+
+ The approach taken with CoA commands in existing implementations
+ results in a semantic ambiguity. Existing implementations of the
+ CoA-Request identify the affected session, as well as supply the
+ authorization changes. Since RADIUS Attributes included within
+ existing implementations of the CoA-Request can be used for session
+ identification or authorization change, it may not be clear which
+ function a given attribute is serving.
+
+ The problem does not exist within [Diameter], in which authorization
+ change is requested by a command using Attribute Value Pairs (AVPs)
+ solely for identification, resulting in initiation of a standard
+ Request/Response sequence where authorization changes are supplied.
+ As a result, in no command can Diameter AVPs have multiple potential
+ meanings.
+
+ Due to differences in handling change-of-authorization requests in
+ RADIUS and Diameter, it may be difficult or impossible for a
+ Diameter/RADIUS gateway to successfully translate existing
+ implementations of this specification to equivalent messages in
+ Diameter. For example, a Diameter command changing any attribute
+ used for identification within existing CoA-Request implementations
+ cannot be translated, since such an authorization change is
+ impossible to carry out in existing implementations. Similarly,
+ translation between existing implementations of Disconnect-Request or
+ CoA-Request messages and Diameter is tricky because a Disconnect-
+ Request or CoA-Request message will need to be translated to multiple
+ Diameter commands.
+
+ To simplify translation between RADIUS and Diameter, a Service-Type
+ Attribute with value "Authorize Only" can (optionally) be included
+ within a Disconnect-Request or CoA-Request. Such a Request contains
+ only identification attributes. A NAS supporting the "Authorize
+ Only" Service-Type within a Disconnect-Request or CoA-Request
+ responds with a NAK containing a Service-Type Attribute with value
+ "Authorize Only" and an Error-Cause Attribute with value "Request
+ Initiated". The NAS will then send an Access-Request containing a
+ Service-Type Attribute with a value of "Authorize Only". This usage
+ sequence is akin to what occurs in Diameter and so is more easily
+ translated by a Diameter/RADIUS gateway.
+
+
+
+
+
+Chiba, et al. Informational [Page 4]
+
+RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
+
+
+1.2. Requirements Language
+
+ 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 [RFC2119].
+
+1.3. Terminology
+
+ This document frequently uses the following terms:
+
+ Network Access Server (NAS): The device providing access to the
+ network.
+
+ service: The NAS provides a service to the user,
+ such as IEEE 802 or PPP.
+
+ session: Each service provided by the NAS to a
+ user constitutes a session, with the
+ beginning of the session defined as the
+ point where service is first provided
+ and the end of the session defined as
+ the point where service is ended. A
+ user may have multiple sessions in
+ parallel or series if the NAS supports
+ that.
+
+ 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. Overview
+
+ This section describes the most commonly implemented features of
+ Disconnect and Change-of-Authorization messages.
+
+2.1. Disconnect Messages (DM)
+
+ A Disconnect-Request packet is sent by the RADIUS server in order to
+ terminate a user session on a NAS and discard all associated session
+ context. The Disconnect-Request packet is sent to UDP port 3799, and
+ identifies the NAS as well as the user session to be terminated by
+ inclusion of the identification attributes described in Section 3.
+
+
+
+Chiba, et al. Informational [Page 5]
+
+RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
+
+
+ +----------+ Disconnect-Request +----------+
+ | | <-------------------- | |
+ | NAS | | RADIUS |
+ | | Disconnect-Response | Server |
+ | | ---------------------> | |
+ +----------+ +----------+
+
+ The NAS responds to a Disconnect-Request packet sent by a RADIUS
+ server with a Disconnect-ACK if all associated session context is
+ discarded and the user session is no longer connected, or a
+ Disconnect-NAK, if the NAS was unable to disconnect the session and
+ discard all associated session context. A NAS MUST respond to a
+ Disconnect-Request including a Service-Type Attribute with value
+ "Authorize Only" with a Disconnect-NAK; a Disconnect-ACK MUST NOT be
+ sent. A NAS MUST respond to a Disconnect-Request including a
+ Service-Type Attribute with an unsupported value with a Disconnect-
+ NAK; an Error-Cause Attribute with value "Unsupported Service" MAY be
+ included. A Disconnect-ACK MAY contain the Attribute
+ Acct-Terminate-Cause (49) [RFC2866] with the value set to 6 for
+ Admin-Reset.
+
+2.2. Change-of-Authorization Messages (CoA)
+
+ CoA-Request packets contain information for dynamically changing
+ session authorizations. This is typically used to change data
+ filters. The data filters can be of either the ingress or egress
+ kind, and are sent in addition to the identification attributes as
+ described in section 3. The port used, and packet format (described
+ in Section 2.3.), are the same as that for Disconnect-Request
+ Messages.
+
+ The following attribute MAY be sent in a CoA-Request:
+
+ Filter-ID (11) - Indicates the name of a data filter list to be
+ applied for the session that the identification
+ attributes map to.
+
+ +----------+ CoA-Request +----------+
+ | | <-------------------- | |
+ | NAS | | RADIUS |
+ | | CoA-Response | Server |
+ | | ---------------------> | |
+ +----------+ +----------+
+
+ The NAS responds to a CoA-Request sent by a RADIUS server with a
+ CoA-ACK if the NAS is able to successfully change the authorizations
+ for the user session, or a CoA-NAK if the Request is unsuccessful. A
+ NAS MUST respond to a CoA-Request including a Service-Type Attribute
+
+
+
+Chiba, et al. Informational [Page 6]
+
+RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
+
+
+ with value "Authorize Only" with a CoA-NAK; a CoA-ACK MUST NOT be
+ sent. A NAS MUST respond to a CoA-Request including a Service-Type
+ Attribute with an unsupported value with a CoA-NAK; an Error-Cause
+ Attribute with value "Unsupported Service" MAY be included.
+
+2.3. Packet Format
+
+ For either Disconnect-Request or CoA-Request messages UDP port 3799
+ is used as the destination port. For responses, the source and
+ destination ports are reversed. Exactly one RADIUS packet is
+ encapsulated in the UDP Data field.
+
+ A summary of the data format is shown below. The fields are
+ transmitted from left to right.
+
+ The packet format consists of the fields: Code, Identifier, Length,
+ Authenticator, and Attributes in Type:Length:Value (TLV) format. All
+ fields hold the same meaning as those described in RADIUS [RFC2865].
+ The Authenticator field MUST be calculated in the same way as is
+ specified for an Accounting-Request in [RFC2866].
+
+ 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ | Authenticator |
+ | |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Attributes ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Code
+
+ The Code field is one octet, and identifies the type of RADIUS
+ packet. Packets received with an invalid Code field MUST be
+ silently discarded. RADIUS codes (decimal) for this extension are
+ assigned as follows:
+
+ 40 - Disconnect-Request [RFC2882]
+ 41 - Disconnect-ACK [RFC2882]
+ 42 - Disconnect-NAK [RFC2882]
+ 43 - CoA-Request [RFC2882]
+ 44 - CoA-ACK [RFC2882]
+ 45 - CoA-NAK [RFC2882]
+
+
+
+
+Chiba, et al. Informational [Page 7]
+
+RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
+
+
+ Identifier
+
+ The Identifier field is one octet, and aids in matching requests
+ and replies. The RADIUS client can detect a duplicate request if
+ it has the same server source IP address and source UDP port and
+ Identifier within a short span of time.
+
+ Unlike RADIUS as defined in [RFC2865], the responsibility for
+ retransmission of Disconnect-Request and CoA-Request messages lies
+ with the RADIUS server. If after sending these messages, the
+ RADIUS server does not receive a response, it will retransmit.
+
+ The Identifier field MUST be changed whenever the content of the
+ Attributes field changes, or whenever a valid reply has been
+ received for a previous request. For retransmissions where the
+ contents are identical, the Identifier MUST remain unchanged.
+
+ If the RADIUS server is retransmitting a Disconnect-Request or
+ CoA-Request to the same client as before, and the Attributes have
+ not changed, the same Request Authenticator, Identifier and source
+ port MUST be used. If any Attributes have changed, a new
+ Authenticator and Identifier MUST be used.
+
+ Note that if the Event-Timestamp Attribute is included, it will be
+ updated when the packet is retransmitted, changing the content of
+ the Attributes field and requiring a new Identifier and Request
+ Authenticator.
+
+ If the Request to a primary proxy fails, a secondary proxy must be
+ queried, if available. Issues relating to failover algorithms are
+ described in [AAATransport]. Since this represents a new request,
+ a new Request Authenticator and Identifier MUST be used. However,
+ where the RADIUS server is sending directly to the client,
+ failover typically does not make sense, since Disconnect or CoA
+ messages need to be delivered to the NAS where the session
+ resides.
+
+ Length
+
+ The Length field is two octets. It indicates the length of the
+ packet including the Code, Identifier, Length, Authenticator and
+ Attribute fields. Octets outside the range of the Length field
+ MUST be treated as padding and ignored on reception. If the
+ packet is shorter than the Length field indicates, it MUST be
+ silently discarded. The minimum length is 20 and the maximum
+ length is 4096.
+
+
+
+
+
+Chiba, et al. Informational [Page 8]
+
+RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
+
+
+ Authenticator
+
+ The Authenticator field is sixteen (16) octets. The most
+ significant octet is transmitted first. This value is used to
+ authenticate the messages between the RADIUS server and client.
+
+ Request Authenticator
+
+ In Request packets, the Authenticator value is a 16 octet MD5
+ [RFC1321] checksum, called the Request Authenticator. The Request
+ Authenticator is calculated the same way as for an Accounting-
+ Request, specified in [RFC2866].
+
+ Note that the Request Authenticator of a Disconnect or CoA-Request
+ cannot be done the same way as the Request Authenticator of a
+ RADIUS Access-Request, because there is no User-Password Attribute
+ in a Disconnect-Request or CoA-Request.
+
+ Response Authenticator
+
+ The Authenticator field in a Response packet (e.g. Disconnect-ACK,
+ Disconnect-NAK, CoA-ACK, or CoA-NAK) is called the Response
+ Authenticator, and contains a one-way MD5 hash calculated over a
+ stream of octets consisting of the Code, Identifier, Length, the
+ Request Authenticator field from the packet being replied to, and
+ the response Attributes if any, followed by the shared secret.
+ The resulting 16 octet MD5 hash value is stored in the
+ Authenticator field of the Response packet.
+
+ Administrative note: As noted in [RFC2865] Section 3, the secret
+ (password shared between the client and the RADIUS server) SHOULD be
+ at least as large and unguessable as a well-chosen password. RADIUS
+ clients MUST use the source IP address of the RADIUS UDP packet to
+ decide which shared secret to use, so that requests can be proxied.
+
+ Attributes
+
+ In Disconnect and CoA-Request messages, all Attributes are treated
+ as mandatory. A NAS MUST respond to a CoA-Request containing one
+ or more unsupported Attributes or Attribute values with a CoA-NAK;
+ a Disconnect-Request containing one or more unsupported Attributes
+ or Attribute values MUST be answered with a Disconnect-NAK. State
+ changes resulting from a CoA-Request MUST be atomic: if the
+ Request is successful, a CoA-ACK is sent, and all requested
+ authorization changes MUST be made. If the CoA-Request is
+ unsuccessful, a CoA-NAK MUST be sent, and the requested
+
+
+
+
+
+Chiba, et al. Informational [Page 9]
+
+RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
+
+
+ authorization changes MUST NOT be made. Similarly, a state change
+ MUST NOT occur as a result of an unsuccessful Disconnect-Request;
+ here a Disconnect-NAK MUST be sent.
+
+ Since within this specification attributes may be used for
+ identification, authorization or other purposes, even if a NAS
+ implements an attribute for use with RADIUS authentication and
+ accounting, it may not support inclusion of that attribute within
+ Disconnect-Request or CoA-Request messages, given the difference
+ in attribute semantics. This is true even for attributes
+ specified within [RFC2865], [RFC2868], [RFC2869] or [RFC3162] as
+ allowable within Access-Accept messages.
+
+ As a result, attributes beyond those specified in Section 3.2.
+ SHOULD NOT be included within Disconnect or CoA messages since
+ this could produce unpredictable results.
+
+ When using a forwarding proxy, the proxy must be able to alter the
+ packet as it passes through in each direction. When the proxy
+ forwards a Disconnect or CoA-Request, it MAY add a Proxy-State
+ Attribute, and when the proxy forwards a response, it MUST remove
+ its Proxy-State Attribute if it added one. Proxy-State is always
+ added or removed after any other Proxy-States, but no other
+ assumptions regarding its location within the list of Attributes
+ can be made. Since Disconnect and CoA responses are authenticated
+ on the entire packet contents, the stripping of the Proxy-State
+ Attribute invalidates the integrity check - so the proxy needs to
+ recompute it. A forwarding proxy MUST NOT modify existing Proxy-
+ State, State, or Class Attributes present in the packet.
+
+ If there are any Proxy-State Attributes in a Disconnect-Request or
+ CoA-Request received from the server, the forwarding proxy MUST
+ include those Proxy-State Attributes in its response to the
+ server. The forwarding proxy MAY include the Proxy-State
+ Attributes in the Disconnect-Request or CoA-Request when it
+ forwards the request, or it MAY omit them in the forwarded
+ request. If the forwarding proxy omits the Proxy-State Attributes
+ in the request, it MUST attach them to the response before sending
+ it to the server.
+
+
+
+
+
+
+
+
+
+
+
+
+Chiba, et al. Informational [Page 10]
+
+RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
+
+
+3. Attributes
+
+ In Disconnect-Request and CoA-Request packets, certain attributes are
+ used to uniquely identify the NAS as well as a user session on the
+ NAS. All NAS identification attributes included in a Request message
+ MUST match in order for a Disconnect-Request or CoA-Request to be
+ successful; otherwise a Disconnect-NAK or CoA-NAK SHOULD be sent.
+ For session identification attributes, the User-Name and Acct-
+ Session-Id Attributes, if included, MUST match in order for a
+ Disconnect-Request or CoA-Request to be successful; other session
+ identification attributes SHOULD match. Where a mismatch of session
+ identification attributes is detected, a Disconnect-NAK or CoA-NAK
+ SHOULD be sent. The ability to use NAS or session identification
+ attributes to map to unique/multiple sessions is beyond the scope of
+ this document. Identification attributes include NAS and session
+ identification attributes, as described below.
+
+ NAS identification attributes
+
+ Attribute # Reference Description
+ --------- --- --------- -----------
+ NAS-IP-Address 4 [RFC2865] The IPv4 address of the NAS.
+ NAS-Identifier 32 [RFC2865] String identifying the NAS.
+ NAS-IPv6-Address 95 [RFC3162] The IPv6 address of the NAS.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chiba, et al. Informational [Page 11]
+
+RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
+
+
+ Session identification attributes
+
+ Attribute # Reference Description
+ --------- --- --------- -----------
+ User-Name 1 [RFC2865] The name of the user
+ associated with the session.
+ NAS-Port 5 [RFC2865] The port on which the
+ session is terminated.
+ Framed-IP-Address 8 [RFC2865] The IPv4 address associated
+ with the session.
+ Called-Station-Id 30 [RFC2865] The link address to which
+ the session is connected.
+ Calling-Station-Id 31 [RFC2865] The link address from which
+ the session is connected.
+ Acct-Session-Id 44 [RFC2866] The identifier uniquely
+ identifying the session
+ on the NAS.
+ Acct-Multi-Session-Id 50 [RFC2866] The identifier uniquely
+ identifying related sessions.
+ NAS-Port-Type 61 [RFC2865] The type of port used.
+ NAS-Port-Id 87 [RFC2869] String identifying the port
+ where the session is.
+ Originating-Line-Info 94 [NASREQ] Provides information on the
+ characteristics of the line
+ from which a session
+ originated.
+ Framed-Interface-Id 96 [RFC3162] The IPv6 Interface Identifier
+ associated with the session;
+ always sent with
+ Framed-IPv6-Prefix.
+ Framed-IPv6-Prefix 97 [RFC3162] The IPv6 prefix associated
+ with the session, always sent
+ with Framed-Interface-Id.
+
+ To address security concerns described in Section 5.1., the User-Name
+ Attribute SHOULD be present in Disconnect-Request or CoA-Request
+ packets; one or more additional session identification attributes MAY
+ also be present. To address security concerns described in Section
+ 5.2., one or more of the NAS-IP-Address or NAS-IPv6-Address
+ Attributes SHOULD be present in Disconnect-Request or CoA-Request
+ packets; the NAS-Identifier Attribute MAY be present in addition.
+
+ If one or more authorization changes specified in a CoA-Request
+ cannot be carried out, or if one or more attributes or attribute-
+ values is unsupported, a CoA-NAK MUST be sent. Similarly, if there
+ are one or more unsupported attributes or attribute values in a
+ Disconnect-Request, a Disconnect-NAK MUST be sent.
+
+
+
+
+Chiba, et al. Informational [Page 12]
+
+RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
+
+
+ Where a Service-Type Attribute with value "Authorize Only" is
+ included within a CoA-Request or Disconnect-Request, attributes
+ representing an authorization change MUST NOT be included; only
+ identification attributes are permitted. If attributes other than
+ NAS or session identification attributes are included in such a CoA-
+ Request, implementations MUST send a CoA-NAK; an Error-Cause
+ Attribute with value "Unsupported Attribute" MAY be included.
+ Similarly, if attributes other than NAS or session identification
+ attributes are included in such a Disconnect-Request, implementations
+ MUST send a Disconnect-NAK; an Error-Cause Attribute with value
+ "Unsupported Attribute" MAY be included.
+
+3.1. Error-Cause
+
+ Description
+
+ It is possible that the NAS cannot honor Disconnect-Request or
+ CoA-Request messages for some reason. The Error-Cause Attribute
+ provides more detail on the cause of the problem. It MAY be
+ included within Disconnect-ACK, Disconnect-NAK and CoA-NAK
+ messages.
+
+ A summary of the Error-Cause Attribute 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 | Value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Value (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 101 for Error-Cause
+
+ Length
+
+ 6
+
+ Value
+
+ The Value field is four octets, containing an integer specifying
+ the cause of the error. Values 0-199 and 300-399 are reserved.
+ Values 200-299 represent successful completion, so that these
+ values may only be sent within Disconnect-ACK or CoA-ACK message
+ and MUST NOT be sent within a Disconnect-NAK or CoA-NAK. Values
+
+
+
+Chiba, et al. Informational [Page 13]
+
+RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
+
+
+ 400-499 represent fatal errors committed by the RADIUS server, so
+ that they MAY be sent within CoA-NAK or Disconnect-NAK messages,
+ and MUST NOT be sent within CoA-ACK or Disconnect-ACK messages.
+ Values 500-599 represent fatal errors occurring on a NAS or RADIUS
+ proxy, so that they MAY be sent within CoA-NAK and Disconnect-NAK
+ messages, and MUST NOT be sent within CoA-ACK or Disconnect-ACK
+ messages. Error-Cause values SHOULD be logged by the RADIUS
+ server. Error-Code values (expressed in decimal) include:
+
+ # Value
+ --- -----
+ 201 Residual Session Context Removed
+ 202 Invalid EAP Packet (Ignored)
+ 401 Unsupported Attribute
+ 402 Missing Attribute
+ 403 NAS Identification Mismatch
+ 404 Invalid Request
+ 405 Unsupported Service
+ 406 Unsupported Extension
+ 501 Administratively Prohibited
+ 502 Request Not Routable (Proxy)
+ 503 Session Context Not Found
+ 504 Session Context Not Removable
+ 505 Other Proxy Processing Error
+ 506 Resources Unavailable
+ 507 Request Initiated
+
+ "Residual Session Context Removed" is sent in response to a
+ Disconnect-Request if the user session is no longer active, but
+ residual session context was found and successfully removed. This
+ value is only sent within a Disconnect-ACK and MUST NOT be sent
+ within a CoA-ACK, Disconnect-NAK or CoA-NAK.
+
+ "Invalid EAP Packet (Ignored)" is a non-fatal error that MUST NOT be
+ sent by implementations of this specification.
+
+ "Unsupported Attribute" is a fatal error sent if a Request contains
+ an attribute (such as a Vendor-Specific or EAP-Message Attribute)
+ that is not supported.
+
+ "Missing Attribute" is a fatal error sent if critical attributes
+ (such as NAS or session identification attributes) are missing from a
+ Request.
+
+ "NAS Identification Mismatch" is a fatal error sent if one or more
+ NAS identification attributes (see Section 3.) do not match the
+ identity of the NAS receiving the Request.
+
+
+
+
+Chiba, et al. Informational [Page 14]
+
+RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
+
+
+ "Invalid Request" is a fatal error sent if some other aspect of the
+ Request is invalid, such as if one or more attributes (such as EAP-
+ Message Attribute(s)) are not formatted properly.
+
+ "Unsupported Service" is a fatal error sent if a Service-Type
+ Attribute included with the Request is sent with an invalid or
+ unsupported value.
+
+ "Unsupported Extension" is a fatal error sent due to lack of support
+ for an extension such as Disconnect and/or CoA messages. This will
+ typically be sent by a proxy receiving an ICMP port unreachable
+ message after attempting to forward a Request to the NAS.
+
+ "Administratively Prohibited" is a fatal error sent if the NAS is
+ configured to prohibit honoring of Request messages for the specified
+ session.
+
+ "Request Not Routable" is a fatal error which MAY be sent by a RADIUS
+ proxy and MUST NOT be sent by a NAS. It indicates that the RADIUS
+ proxy was unable to determine how to route the Request to the NAS.
+ For example, this can occur if the required entries are not present
+ in the proxy's realm routing table.
+
+ "Session Context Not Found" is a fatal error sent if the session
+ context identified in the Request does not exist on the NAS.
+
+ "Session Context Not Removable" is a fatal error sent in response to
+ a Disconnect-Request if the NAS was able to locate the session
+ context, but could not remove it for some reason. It MUST NOT be
+ sent within a CoA-ACK, CoA-NAK or Disconnect-ACK, only within a
+ Disconnect-NAK.
+
+ "Other Proxy Processing Error" is a fatal error sent in response to a
+ Request that could not be processed by a proxy, for reasons other
+ than routing.
+
+ "Resources Unavailable" is a fatal error sent when a Request could
+ not be honored due to lack of available NAS resources (memory, non-
+ volatile storage, etc.).
+
+ "Request Initiated" is a fatal error sent in response to a Request
+ including a Service-Type Attribute with a value of "Authorize Only".
+ It indicates that the Disconnect-Request or CoA-Request has not been
+ honored, but that a RADIUS Access-Request including a Service-Type
+ Attribute with value "Authorize Only" is being sent to the RADIUS
+ server.
+
+
+
+
+
+Chiba, et al. Informational [Page 15]
+
+RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
+
+
+3.2. Table of Attributes
+
+ The following table provides a guide to which attributes may be found
+ in which packets, and in what quantity.
+
+ Change-of-Authorization Messages
+
+ Request ACK NAK # Attribute
+ 0-1 0 0 1 User-Name [Note 1]
+ 0-1 0 0 4 NAS-IP-Address [Note 1]
+ 0-1 0 0 5 NAS-Port [Note 1]
+ 0-1 0 0-1 6 Service-Type [Note 6]
+ 0-1 0 0 7 Framed-Protocol [Note 3]
+ 0-1 0 0 8 Framed-IP-Address [Note 1]
+ 0-1 0 0 9 Framed-IP-Netmask [Note 3]
+ 0-1 0 0 10 Framed-Routing [Note 3]
+ 0+ 0 0 11 Filter-ID [Note 3]
+ 0-1 0 0 12 Framed-MTU [Note 3]
+ 0+ 0 0 13 Framed-Compression [Note 3]
+ 0+ 0 0 14 Login-IP-Host [Note 3]
+ 0-1 0 0 15 Login-Service [Note 3]
+ 0-1 0 0 16 Login-TCP-Port [Note 3]
+ 0+ 0 0 18 Reply-Message [Note 2]
+ 0-1 0 0 19 Callback-Number [Note 3]
+ 0-1 0 0 20 Callback-Id [Note 3]
+ 0+ 0 0 22 Framed-Route [Note 3]
+ 0-1 0 0 23 Framed-IPX-Network [Note 3]
+ 0-1 0-1 0-1 24 State [Note 7]
+ 0+ 0 0 25 Class [Note 3]
+ 0+ 0 0 26 Vendor-Specific [Note 3]
+ 0-1 0 0 27 Session-Timeout [Note 3]
+ 0-1 0 0 28 Idle-Timeout [Note 3]
+ 0-1 0 0 29 Termination-Action [Note 3]
+ 0-1 0 0 30 Called-Station-Id [Note 1]
+ 0-1 0 0 31 Calling-Station-Id [Note 1]
+ 0-1 0 0 32 NAS-Identifier [Note 1]
+ 0+ 0+ 0+ 33 Proxy-State
+ 0-1 0 0 34 Login-LAT-Service [Note 3]
+ 0-1 0 0 35 Login-LAT-Node [Note 3]
+ 0-1 0 0 36 Login-LAT-Group [Note 3]
+ 0-1 0 0 37 Framed-AppleTalk-Link [Note 3]
+ 0+ 0 0 38 Framed-AppleTalk-Network [Note 3]
+ 0-1 0 0 39 Framed-AppleTalk-Zone [Note 3]
+ 0-1 0 0 44 Acct-Session-Id [Note 1]
+ 0-1 0 0 50 Acct-Multi-Session-Id [Note 1]
+ 0-1 0-1 0-1 55 Event-Timestamp
+ 0-1 0 0 61 NAS-Port-Type [Note 1]
+ Request ACK NAK # Attribute
+
+
+
+Chiba, et al. Informational [Page 16]
+
+RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
+
+
+ Request ACK NAK # Attribute
+ 0-1 0 0 62 Port-Limit [Note 3]
+ 0-1 0 0 63 Login-LAT-Port [Note 3]
+ 0+ 0 0 64 Tunnel-Type [Note 5]
+ 0+ 0 0 65 Tunnel-Medium-Type [Note 5]
+ 0+ 0 0 66 Tunnel-Client-Endpoint [Note 5]
+ 0+ 0 0 67 Tunnel-Server-Endpoint [Note 5]
+ 0+ 0 0 69 Tunnel-Password [Note 5]
+ 0-1 0 0 71 ARAP-Features [Note 3]
+ 0-1 0 0 72 ARAP-Zone-Access [Note 3]
+ 0+ 0 0 78 Configuration-Token [Note 3]
+ 0+ 0-1 0 79 EAP-Message [Note 2]
+ 0-1 0-1 0-1 80 Message-Authenticator
+ 0+ 0 0 81 Tunnel-Private-Group-ID [Note 5]
+ 0+ 0 0 82 Tunnel-Assignment-ID [Note 5]
+ 0+ 0 0 83 Tunnel-Preference [Note 5]
+ 0-1 0 0 85 Acct-Interim-Interval [Note 3]
+ 0-1 0 0 87 NAS-Port-Id [Note 1]
+ 0-1 0 0 88 Framed-Pool [Note 3]
+ 0+ 0 0 90 Tunnel-Client-Auth-ID [Note 5]
+ 0+ 0 0 91 Tunnel-Server-Auth-ID [Note 5]
+ 0-1 0 0 94 Originating-Line-Info [Note 1]
+ 0-1 0 0 95 NAS-IPv6-Address [Note 1]
+ 0-1 0 0 96 Framed-Interface-Id [Note 1]
+ 0+ 0 0 97 Framed-IPv6-Prefix [Note 1]
+ 0+ 0 0 98 Login-IPv6-Host [Note 3]
+ 0+ 0 0 99 Framed-IPv6-Route [Note 3]
+ 0-1 0 0 100 Framed-IPv6-Pool [Note 3]
+ 0 0 0+ 101 Error-Cause
+ Request ACK NAK # Attribute
+
+ Disconnect Messages
+
+ Request ACK NAK # Attribute
+ 0-1 0 0 1 User-Name [Note 1]
+ 0-1 0 0 4 NAS-IP-Address [Note 1]
+ 0-1 0 0 5 NAS-Port [Note 1]
+ 0-1 0 0-1 6 Service-Type [Note 6]
+ 0-1 0 0 8 Framed-IP-Address [Note 1]
+ 0+ 0 0 18 Reply-Message [Note 2]
+ 0-1 0-1 0-1 24 State [Note 7]
+ 0+ 0 0 25 Class [Note 4]
+ 0+ 0 0 26 Vendor-Specific
+ 0-1 0 0 30 Called-Station-Id [Note 1]
+ 0-1 0 0 31 Calling-Station-Id [Note 1]
+ 0-1 0 0 32 NAS-Identifier [Note 1]
+ 0+ 0+ 0+ 33 Proxy-State
+ Request ACK NAK # Attribute
+
+
+
+Chiba, et al. Informational [Page 17]
+
+RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
+
+
+ Request ACK NAK # Attribute
+ 0-1 0 0 44 Acct-Session-Id [Note 1]
+ 0-1 0-1 0 49 Acct-Terminate-Cause
+ 0-1 0 0 50 Acct-Multi-Session-Id [Note 1]
+ 0-1 0-1 0-1 55 Event-Timestamp
+ 0-1 0 0 61 NAS-Port-Type [Note 1]
+ 0+ 0-1 0 79 EAP-Message [Note 2]
+ 0-1 0-1 0-1 80 Message-Authenticator
+ 0-1 0 0 87 NAS-Port-Id [Note 1]
+ 0-1 0 0 94 Originating-Line-Info [Note 1]
+ 0-1 0 0 95 NAS-IPv6-Address [Note 1]
+ 0-1 0 0 96 Framed-Interface-Id [Note 1]
+ 0+ 0 0 97 Framed-IPv6-Prefix [Note 1]
+ 0 0+ 0+ 101 Error-Cause
+ Request ACK NAK # Attribute
+
+ [Note 1] Where NAS or session identification attributes are included
+ in Disconnect-Request or CoA-Request messages, they are used for
+ identification purposes only. These attributes MUST NOT be used for
+ purposes other than identification (e.g. within CoA-Request messages
+ to request authorization changes).
+
+ [Note 2] The Reply-Message Attribute is used to present a displayable
+ message to the user. The message is only displayed as a result of a
+ successful Disconnect-Request or CoA-Request (where a Disconnect-ACK
+ or CoA-ACK is subsequently sent). Where EAP is used for
+ authentication, an EAP-Message/Notification-Request Attribute is sent
+ instead, and Disconnect-ACK or CoA-ACK messages contain an EAP-
+ Message/Notification-Response Attribute.
+
+ [Note 3] When included within a CoA-Request, these attributes
+ represent an authorization change request. When one of these
+ attributes is omitted from a CoA-Request, the NAS assumes that the
+ attribute value is to remain unchanged. Attributes included in a
+ CoA-Request replace all existing value(s) of the same attribute(s).
+
+ [Note 4] When included within a successful Disconnect-Request (where
+ a Disconnect-ACK is subsequently sent), the Class Attribute SHOULD be
+ sent unmodified by the client to the accounting server in the
+ Accounting Stop packet. If the Disconnect-Request is unsuccessful,
+ then the Class Attribute is not processed.
+
+ [Note 5] When included within a CoA-Request, these attributes
+ represent an authorization change request. Where tunnel attribute(s)
+ are sent within a successful CoA-Request, all existing tunnel
+ attributes are removed and replaced by the new attribute(s).
+
+
+
+
+
+Chiba, et al. Informational [Page 18]
+
+RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
+
+
+ [Note 6] When included within a Disconnect-Request or CoA-Request, a
+ Service-Type Attribute with value "Authorize Only" indicates that the
+ Request only contains NAS and session identification attributes, and
+ that the NAS should attempt reauthorization by sending an Access-
+ Request with a Service-Type Attribute with value "Authorize Only".
+ This enables a usage model akin to that supported in Diameter, thus
+ easing translation between the two protocols. Support for the
+ Service-Type Attribute is optional within CoA-Request and
+ Disconnect-Request messages; where it is not included, the Request
+ message may contain both identification and authorization attributes.
+ A NAS that does not support the Service-Type Attribute with the value
+ "Authorize Only" within a Disconnect-Request MUST respond with a
+ Disconnect-NAK including no Service-Type Attribute; an Error-Cause
+ Attribute with value "Unsupported Service" MAY be included. A NAS
+ that does not support the Service-Type Attribute with the value
+ "Authorize Only" within a CoA-Request MUST respond with a CoA-NAK
+ including no Service-Type Attribute; an Error-Cause Attribute with
+ value "Unsupported Service" MAY be included.
+
+ A NAS supporting the "Authorize Only" Service-Type value within
+ Disconnect-Request or CoA-Request messages MUST respond with a
+ Disconnect-NAK or CoA-NAK respectively, containing a Service-Type
+ Attribute with value "Authorize Only", and an Error-Cause Attribute
+ with value "Request Initiated". The NAS then sends an Access-Request
+ to the RADIUS server with a Service-Type Attribute with value
+ "Authorize Only". This Access-Request SHOULD contain the NAS
+ attributes from the Disconnect or CoA-Request, as well as the session
+ attributes from the Request legal for inclusion in an Access-Request
+ as specified in [RFC2865], [RFC2868], [RFC2869] and [RFC3162]. As
+ noted in [RFC2869] Section 5.19, a Message-Authenticator attribute
+ SHOULD be included in an Access-Request that does not contain a
+ User-Password, CHAP-Password, ARAP-Password or EAP-Message Attribute.
+ The RADIUS server should send back an Access-Accept to (re-)authorize
+ the session or an Access-Reject to refuse to (re-)authorize it.
+
+ [Note 7] The State Attribute is available to be sent by the RADIUS
+ server to the NAS in a Disconnect-Request or CoA-Request message and
+ MUST be sent unmodified from the NAS to the RADIUS server in a
+ subsequent ACK or NAK message. If a Service-Type Attribute with
+ value "Authorize Only" is included in a Disconnect-Request or CoA-
+ Request along with a State Attribute, then the State Attribute MUST
+ be sent unmodified from the NAS to the RADIUS server in the resulting
+ Access-Request sent to the RADIUS server, if any. The State
+ Attribute is also available to be sent by the RADIUS server to the
+ NAS in a CoA-Request that also includes a Termination-Action
+ Attribute with the value of RADIUS-Request. If the client performs
+ the Termination-Action by sending a new Access-Request upon
+ termination of the current session, it MUST include the State
+
+
+
+Chiba, et al. Informational [Page 19]
+
+RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
+
+
+ Attribute unchanged in that Access-Request. In either usage, the
+ client MUST NOT interpret the Attribute locally. A Disconnect-
+ Request or CoA-Request packet must have only zero or one State
+ Attribute. Usage of the State Attribute is implementation dependent.
+ If the RADIUS server does not recognize the State Attribute in the
+ Access-Request, then it MUST send an Access-Reject.
+
+ The following table defines the meaning of the above table entries.
+
+ 0 This attribute MUST NOT be present in packet.
+ 0+ Zero or more instances of this attribute MAY be present in
+ packet.
+ 0-1 Zero or one instance of this attribute MAY be present in packet.
+ 1 Exactly one instance of this attribute MUST be present in packet.
+
+4. IANA Considerations
+
+ This document uses the RADIUS [RFC2865] namespace, see
+ <http://www.iana.org/assignments/radius-types>. There are six
+ updates for the section: RADIUS Packet Type Codes. These Packet
+ Types are allocated in [RADIANA]:
+
+ 40 - Disconnect-Request
+ 41 - Disconnect-ACK
+ 42 - Disconnect-NAK
+ 43 - CoA-Request
+ 44 - CoA-ACK
+ 45 - CoA-NAK
+
+ Allocation of a new Service-Type value for "Authorize Only" is
+ requested. This document also uses the UDP [RFC768] namespace, see
+ <http://www.iana.org/assignments/port-numbers>. The authors request
+ a port assignment from the Registered ports range. Finally, this
+ specification allocates the Error-Cause Attribute (101) with the
+ following decimal values:
+
+ # Value
+ --- -----
+ 201 Residual Session Context Removed
+ 202 Invalid EAP Packet (Ignored)
+ 401 Unsupported Attribute
+ 402 Missing Attribute
+ 403 NAS Identification Mismatch
+ 404 Invalid Request
+ 405 Unsupported Service
+ 406 Unsupported Extension
+ 501 Administratively Prohibited
+ 502 Request Not Routable (Proxy)
+
+
+
+Chiba, et al. Informational [Page 20]
+
+RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
+
+
+ 503 Session Context Not Found
+ 504 Session Context Not Removable
+ 505 Other Proxy Processing Error
+ 506 Resources Unavailable
+ 507 Request Initiated
+
+5. Security Considerations
+
+5.1. Authorization Issues
+
+ Where a NAS is shared by multiple providers, it is undesirable for
+ one provider to be able to send Disconnect-Request or CoA-Requests
+ affecting the sessions of another provider.
+
+ A NAS or RADIUS proxy MUST silently discard Disconnect-Request or
+ CoA-Request messages from untrusted sources. By default, a RADIUS
+ proxy SHOULD perform a "reverse path forwarding" (RPF) check to
+ verify that a Disconnect-Request or CoA-Request originates from an
+ authorized RADIUS server. In addition, it SHOULD be possible to
+ explicitly authorize additional sources of Disconnect-Request or
+ CoA-Request packets relating to certain classes of sessions. For
+ example, a particular source can be explicitly authorized to send
+ CoA-Request messages relating to users within a set of realms.
+
+ To perform the RPF check, the proxy uses the session identification
+ attributes included in Disconnect-Request or CoA-Request messages, in
+ order to determine the RADIUS server(s) to which an equivalent
+ Access-Request could be routed. If the source address of the
+ Disconnect-Request or CoA-Request is within this set, then the
+ Request is forwarded; otherwise it MUST be silently discarded.
+
+ Typically the proxy will extract the realm from the Network Access
+ Identifier [RFC2486] included within the User-Name Attribute, and
+ determine the corresponding RADIUS servers in the proxy routing
+ tables. The RADIUS servers for that realm are then compared against
+ the source address of the packet. Where no RADIUS proxy is present,
+ the RPF check will need to be performed by the NAS itself.
+
+ Since authorization to send a Disconnect-Request or CoA-Request is
+ determined based on the source address and the corresponding shared
+ secret, the NASes or proxies SHOULD configure a different shared
+ secret for each RADIUS server.
+
+
+
+
+
+
+
+
+
+Chiba, et al. Informational [Page 21]
+
+RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
+
+
+5.2. Impersonation
+
+ [RFC2865] Section 3 states:
+
+ A RADIUS server MUST use the source IP address of the RADIUS UDP
+ packet to decide which shared secret to use, so that RADIUS
+ requests can be proxied.
+
+ When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or
+ NAS-IPv6-Address Attributes will typically not match the source
+ address observed by the RADIUS server. Since the NAS-Identifier
+ Attribute need not contain an FQDN, this attribute may not be
+ resolvable to the source address observed by the RADIUS server, even
+ when no proxy is present.
+
+ As a result, the authenticity check performed by a RADIUS server or
+ proxy does not verify the correctness of NAS identification
+ attributes. This makes it possible for a rogue NAS to forge NAS-IP-
+ Address, NAS-IPv6-Address or NAS-Identifier Attributes within a
+ RADIUS Access-Request in order to impersonate another NAS. It is
+ also possible for a rogue NAS to forge session identification
+ attributes such as the Called-Station-Id, Calling-Station-Id, or
+ Originating-Line-Info [NASREQ]. This could fool the RADIUS server
+ into sending Disconnect-Request or CoA-Request messages containing
+ forged session identification attributes to a NAS targeted by an
+ attacker.
+
+ To address these vulnerabilities RADIUS proxies SHOULD check whether
+ NAS identification attributes (see Section 3.) match the source
+ address of packets originating from the NAS. Where one or more
+ attributes do not match, Disconnect-Request or CoA-Request messages
+ SHOULD be silently discarded.
+
+ Such a check may not always be possible. Since the NAS-Identifier
+ Attribute need not correspond to an FQDN, it may not be resolvable to
+ an IP address to be matched against the source address. Also, where
+ a NAT exists between the RADIUS client and proxy, checking the NAS-
+ IP-Address or NAS-IPv6-Address Attributes may not be feasible.
+
+5.3. IPsec Usage Guidelines
+
+ In addition to security vulnerabilities unique to Disconnect or CoA
+ messages, the protocol exchanges described in this document are
+ susceptible to the same vulnerabilities as RADIUS [RFC2865]. It is
+ RECOMMENDED that IPsec be employed to afford better security.
+
+
+
+
+
+
+Chiba, et al. Informational [Page 22]
+
+RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
+
+
+ Implementations of this specification SHOULD support IPsec [RFC2401]
+ along with IKE [RFC2409] for key management. IPsec ESP [RFC2406]
+ with a non-null transform SHOULD be supported, and IPsec ESP with a
+ non-null encryption transform and authentication support SHOULD be
+ used to provide per-packet confidentiality, authentication, integrity
+ and replay protection. IKE SHOULD be used for key management.
+
+ Within RADIUS [RFC2865], a shared secret is used for hiding
+ Attributes such as User-Password, as well as used in computation of
+ the Response Authenticator. In RADIUS accounting [RFC2866], the
+ shared secret is used in computation of both the Request
+ Authenticator and the Response Authenticator.
+
+ Since in RADIUS a shared secret is used to provide confidentiality as
+ well as integrity protection and authentication, only use of IPsec
+ ESP with a non-null transform can provide security services
+ sufficient to substitute for RADIUS application-layer security.
+ Therefore, where IPsec AH or ESP null is used, it will typically
+ still be necessary to configure a RADIUS shared secret.
+
+ Where RADIUS is run over IPsec ESP with a non-null transform, the
+ secret shared between the NAS and the RADIUS server MAY NOT be
+ configured. In this case, a shared secret of zero length MUST be
+ assumed. However, a RADIUS server that cannot know whether incoming
+ traffic is IPsec-protected MUST be configured with a non-null RADIUS
+ shared secret.
+
+ When IPsec ESP is used with RADIUS, per-packet authentication,
+ integrity and replay protection MUST be used. 3DES-CBC MUST be
+ supported as an encryption transform and AES-CBC SHOULD be supported.
+ AES-CBC SHOULD be offered as a preferred encryption transform if
+ supported. HMAC-SHA1-96 MUST be supported as an authentication
+ transform. DES-CBC SHOULD NOT be used as the encryption transform.
+
+ A typical IPsec policy for an IPsec-capable RADIUS client is
+ "Initiate IPsec, from me to any destination port UDP 1812". This
+ IPsec policy causes an IPsec SA to be set up by the RADIUS client
+ prior to sending RADIUS traffic. If some RADIUS servers contacted by
+ the client do not support IPsec, then a more granular policy will be
+ required: "Initiate IPsec, from me to IPsec-Capable-RADIUS-Server,
+ destination port UDP 1812."
+
+ For a client implementing this specification, the policy would be
+ "Accept IPsec, from any to me, destination port UDP 3799". This
+ causes the RADIUS client to accept (but not require) use of IPsec.
+ It may not be appropriate to require IPsec for all RADIUS servers
+ connecting to an IPsec-enabled RADIUS client, since some RADIUS
+ servers may not support IPsec.
+
+
+
+Chiba, et al. Informational [Page 23]
+
+RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
+
+
+ For an IPsec-capable RADIUS server, a typical IPsec policy is "Accept
+ IPsec, from any to me, destination port 1812". This causes the
+ RADIUS server to accept (but not require) use of IPsec. It may not
+ be appropriate to require IPsec for all RADIUS clients connecting to
+ an IPsec-enabled RADIUS server, since some RADIUS clients may not
+ support IPsec.
+
+ For servers implementing this specification, the policy would be
+ "Initiate IPsec, from me to any, destination port UDP 3799". This
+ causes the RADIUS server to initiate IPsec when sending RADIUS
+ extension traffic to any RADIUS client. If some RADIUS clients
+ contacted by the server do not support IPsec, then a more granular
+ policy will be required, such as "Initiate IPsec, from me to IPsec-
+ capable-RADIUS-client, destination port UDP 3799".
+
+ Where IPsec is used for security, and no RADIUS shared secret is
+ configured, it is important that the RADIUS client and server perform
+ an authorization check. Before enabling a host to act as a RADIUS
+ client, the RADIUS server SHOULD check whether the host is authorized
+ to provide network access. Similarly, before enabling a host to act
+ as a RADIUS server, the RADIUS client SHOULD check whether the host
+ is authorized for that role.
+
+ RADIUS servers can be configured with the IP addresses (for IKE
+ Aggressive Mode with pre-shared keys) or FQDNs (for certificate
+ authentication) of RADIUS clients. Alternatively, if a separate
+ Certification Authority (CA) exists for RADIUS clients, then the
+ RADIUS server can configure this CA as a trust anchor [RFC3280] for
+ use with IPsec.
+
+ Similarly, RADIUS clients can be configured with the IP addresses
+ (for IKE Aggressive Mode with pre-shared keys) or FQDNs (for
+ certificate authentication) of RADIUS servers. Alternatively, if a
+ separate CA exists for RADIUS servers, then the RADIUS client can
+ configure this CA as a trust anchor for use with IPsec.
+
+ Since unlike SSL/TLS, IKE does not permit certificate policies to be
+ set on a per-port basis, certificate policies need to apply to all
+ uses of IPsec on RADIUS clients and servers. In IPsec deployment
+ supporting only certificate authentication, a management station
+ initiating an IPsec-protected telnet session to the RADIUS server
+ would need to obtain a certificate chaining to the RADIUS client CA.
+ Issuing such a certificate might not be appropriate if the management
+ station was not authorized as a RADIUS client.
+
+ Where RADIUS clients may obtain their IP address dynamically (such as
+ an Access Point supporting DHCP), Main Mode with pre-shared keys
+ [RFC2409] SHOULD NOT be used, since this requires use of a group
+
+
+
+Chiba, et al. Informational [Page 24]
+
+RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
+
+
+ pre-shared key; instead, Aggressive Mode SHOULD be used. Where
+ RADIUS client addresses are statically assigned, either Aggressive
+ Mode or Main Mode MAY be used. With certificate authentication, Main
+ Mode SHOULD be used.
+
+ Care needs to be taken with IKE Phase 1 Identity Payload selection in
+ order to enable mapping of identities to pre-shared keys, even with
+ Aggressive Mode. Where the ID_IPV4_ADDR or ID_IPV6_ADDR Identity
+ Payloads are used and addresses are dynamically assigned, mapping of
+ identities to keys is not possible, so that group pre-shared keys are
+ still a practical necessity. As a result, the ID_FQDN identity
+ payload SHOULD be employed in situations where Aggressive mode is
+ utilized along with pre-shared keys and IP addresses are dynamically
+ assigned. This approach also has other advantages, since it allows
+ the RADIUS server and client to configure themselves based on the
+ fully qualified domain name of their peers.
+
+ Note that with IPsec, security services are negotiated at the
+ granularity of an IPsec SA, so that RADIUS exchanges requiring a set
+ of security services different from those negotiated with existing
+ IPsec SAs will need to negotiate a new IPsec SA. Separate IPsec SAs
+ are also advisable where quality of service considerations dictate
+ different handling RADIUS conversations. Attempting to apply
+ different quality of service to connections handled by the same IPsec
+ SA can result in reordering, and falling outside the replay window.
+ For a discussion of the issues, see [RFC2983].
+
+5.4. Replay Protection
+
+ Where IPsec replay protection is not used, the Event-Timestamp (55)
+ Attribute [RFC2869] SHOULD be included within all messages. When
+ this attribute is present, both the NAS and the RADIUS server MUST
+ check that the Event-Timestamp Attribute is current within an
+ acceptable time window. If the Event-Timestamp Attribute is not
+ current, then the message MUST be silently discarded. This implies
+ the need for time synchronization within the network, which can be
+ achieved by a variety of means, including secure NTP, as described in
+ [NTPAUTH].
+
+ Both the NAS and the RADIUS server SHOULD be configurable to silently
+ discard messages lacking an Event-Timestamp Attribute. A default
+ time window of 300 seconds is recommended.
+
+
+
+
+
+
+
+
+
+Chiba, et al. Informational [Page 25]
+
+RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
+
+
+6. Example Traces
+
+ Disconnect Request with User-Name:
+
+ 0: xxxx xxxx xxxx xxxx xxxx 2801 001c 1b23 .B.....$.-(....#
+ 16: 624c 3543 ceba 55f1 be55 a714 ca5e 0108 bL5C..U..U...^..
+ 32: 6d63 6869 6261
+
+ Disconnect Request with Acct-Session-ID:
+
+ 0: xxxx xxxx xxxx xxxx xxxx 2801 001e ad0d .B..... ~.(.....
+ 16: 8e53 55b6 bd02 a0cb ace6 4e38 77bd 2c0a .SU.......N8w.,.
+ 32: 3930 3233 3435 3637 90234567
+
+ Disconnect Request with Framed-IP-Address:
+
+ 0: xxxx xxxx xxxx xxxx xxxx 2801 001a 0bda .B....."2.(.....
+ 16: 33fe 765b 05f0 fd9c c32a 2f6b 5182 0806 3.v[.....*/kQ...
+ 32: 0a00 0203
+
+7. References
+
+7.1. Normative References
+
+ [RFC1305] Mills, D., "Network Time Protocol (version 3)
+ Specification, Implementation and Analysis", RFC 1305,
+ March 1992.
+
+ [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC
+ 1321, April 1992.
+
+ [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
+ Keyed-Hashing for Message Authentication", RFC 2104,
+ February 1997.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
+ the Internet Protocol", RFC 2401, November 1998.
+
+ [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
+ Payload (ESP)", RFC 2406, November 1998.
+
+ [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
+ (IKE)", RFC 2409, November 1998.
+
+
+
+
+
+Chiba, et al. Informational [Page 26]
+
+RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
+
+
+ [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
+ an IANA Considerations Section in RFCs", BCP 26, RFC
+ 2434, October 1998.
+
+ [RFC2486] Aboba, B. and M. Beadles, "The Network Access
+ Identifier", RFC 2486, January 1999.
+
+ [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson,
+ "Remote Authentication Dial In User Service (RADIUS)",
+ RFC 2865, June 2000.
+
+ [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
+
+ [RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS
+ Extensions", RFC 2869, June 2000.
+
+ [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6",
+ RFC 3162, August 2001.
+
+ [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
+ X.509 Public Key Infrastructure Certificate and
+ Certificate Revocation List (CRL) Profile", RFC 3280,
+ April 2002.
+
+ [RADIANA] Aboba, B., "IANA Considerations for RADIUS (Remote
+ Authentication Dial In User Service)", RFC 3575, July
+ 2003.
+
+7.2. Informative References
+
+ [RFC2882] Mitton, D., "Network Access Server Requirements:
+ Extended RADIUS Practices", RFC 2882, July 2000.
+
+ [RFC2983] Black, D. "Differentiated Services and Tunnels", RFC
+ 2983, October 2000.
+
+ [AAATransport] Aboba, B. and J. Wood, "Authentication, Authorization
+ and Accounting (AAA) Transport Profile", RFC 3539,
+ June 2003.
+
+ [Diameter] Calhoun, P., et al., "Diameter Base Protocol", Work in
+ Progress.
+
+ [MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent
+ Attack", CryptoBytes Vol.2 No.2, Summer 1996.
+
+ [NASREQ] Calhoun, P., et al., "Diameter Network Access Server
+ Application", Work in Progress.
+
+
+
+Chiba, et al. Informational [Page 27]
+
+RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
+
+
+ [NTPAUTH] Mills, D., "Public Key Cryptography for the Network
+ Time Protocol", Work in Progress.
+
+8. Intellectual Property Statement
+
+ 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 implementers 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.
+
+9. Acknowledgments
+
+ This protocol was first developed and distributed by Ascend
+ Communications. Example code was distributed in their free server
+ kit.
+
+ The authors would like to acknowledge the valuable suggestions and
+ feedback from the following people:
+
+ Avi Lior <avi@bridgewatersystems.com>,
+ Randy Bush <randy@psg.net>,
+ Steve Bellovin <smb@research.att.com>
+ Glen Zorn <gwz@cisco.com>,
+ Mark Jones <mjones@bridgewatersystems.com>,
+ Claudio Lapidus <clapidus@hotmail.com>,
+ Anurag Batta <Anurag_Batta@3com.com>,
+ Kuntal Chowdhury <chowdury@nortelnetworks.com>, and
+ Tim Moore <timmoore@microsoft.com>.
+ Russ Housley <housley@vigilsec.com>
+
+
+
+
+
+
+
+Chiba, et al. Informational [Page 28]
+
+RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
+
+
+10. Authors' Addresses
+
+ Murtaza Chiba
+ Cisco Systems, Inc.
+ 170 West Tasman Dr.
+ San Jose CA, 95134
+
+ EMail: mchiba@cisco.com
+ Phone: +1 408 525 7198
+
+ Gopal Dommety
+ Cisco Systems, Inc.
+ 170 West Tasman Dr.
+ San Jose, CA 95134
+
+ EMail: gdommety@cisco.com
+ Phone: +1 408 525 1404
+
+ Mark Eklund
+ Cisco Systems, Inc.
+ 170 West Tasman Dr.
+ San Jose, CA 95134
+
+ EMail: meklund@cisco.com
+ Phone: +1 865 671 6255
+
+ David Mitton
+ Circular Logic UnLtd.
+ 733 Turnpike Street #154
+ North Andover, MA 01845
+
+ EMail: david@mitton.com
+ Phone: +1 978 683 1814
+
+ Bernard Aboba
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052
+
+ EMail: bernarda@microsoft.com
+ Phone: +1 425 706 6605
+ Fax: +1 425 936 7329
+
+
+
+
+
+
+
+
+
+Chiba, et al. Informational [Page 29]
+
+RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003
+
+
+11. 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chiba, et al. Informational [Page 30]
+
diff --git a/rfc/rfc3580.txt b/rfc/rfc3580.txt
new file mode 100644
index 0000000..b87235c
--- /dev/null
+++ b/rfc/rfc3580.txt
@@ -0,0 +1,1683 @@
+
+
+
+
+
+
+Network Working Group P. Congdon
+Request for Comments: 3580 Hewlett Packard Company
+Category: Informational B. Aboba
+ Microsoft
+ A. Smith
+ Trapeze Networks
+ G. Zorn
+ Cisco Systems
+ J. Roese
+ Enterasys
+ September 2003
+
+
+ IEEE 802.1X Remote Authentication Dial In User Service (RADIUS)
+ Usage Guidelines
+
+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 (2003). All Rights Reserved.
+
+Abstract
+
+ This document provides suggestions on Remote Authentication Dial In
+ User Service (RADIUS) usage by IEEE 802.1X Authenticators. The
+ material in this document is also included within a non-normative
+ Appendix within the IEEE 802.1X specification, and is being presented
+ as an IETF RFC for informational purposes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Congdon, et al. Informational [Page 1]
+
+RFC 3580 IEEE 802.1X RADIUS September 2003
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. Terminology. . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.2. Requirements Language. . . . . . . . . . . . . . . . . . 4
+ 2. RADIUS Accounting Attributes . . . . . . . . . . . . . . . . . 5
+ 2.1. Acct-Terminate-Cause . . . . . . . . . . . . . . . . . . 5
+ 2.2. Acct-Multi-Session-Id. . . . . . . . . . . . . . . . . . 6
+ 2.3. Acct-Link-Count. . . . . . . . . . . . . . . . . . . . . 7
+ 3. RADIUS Authentication. . . . . . . . . . . . . . . . . . . . . 7
+ 3.1. User-Name. . . . . . . . . . . . . . . . . . . . . . . . 8
+ 3.2. User-Password, CHAP-Password, CHAP-Challenge . . . . . . 8
+ 3.3. NAS-IP-Address, NAS-IPv6-Address . . . . . . . . . . . . 8
+ 3.4. NAS-Port . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 3.5. Service-Type . . . . . . . . . . . . . . . . . . . . . . 8
+ 3.6. Framed-Protocol. . . . . . . . . . . . . . . . . . . . . 9
+ 3.7. Framed-IP-Address, Framed-IP-Netmask . . . . . . . . . . 9
+ 3.8. Framed-Routing . . . . . . . . . . . . . . . . . . . . . 9
+ 3.9. Filter-ID. . . . . . . . . . . . . . . . . . . . . . . . 9
+ 3.10. Framed-MTU . . . . . . . . . . . . . . . . . . . . . . . 9
+ 3.11. Framed-Compression . . . . . . . . . . . . . . . . . . . 10
+ 3.12. Displayable Messages . . . . . . . . . . . . . . . . . . 10
+ 3.13. Callback-Number, Callback-ID . . . . . . . . . . . . . . 10
+ 3.14. Framed-Route, Framed-IPv6-Route. . . . . . . . . . . . . 11
+ 3.15. State, Class, Proxy-State. . . . . . . . . . . . . . . . 11
+ 3.16. Vendor-Specific. . . . . . . . . . . . . . . . . . . . . 11
+ 3.17. Session-Timeout. . . . . . . . . . . . . . . . . . . . . 11
+ 3.18. Idle-Timeout . . . . . . . . . . . . . . . . . . . . . . 12
+ 3.19. Termination-Action . . . . . . . . . . . . . . . . . . . 12
+ 3.20. Called-Station-Id. . . . . . . . . . . . . . . . . . . . 12
+ 3.21. Calling-Station-Id . . . . . . . . . . . . . . . . . . . 12
+ 3.22. NAS-Identifier . . . . . . . . . . . . . . . . . . . . . 12
+ 3.23. NAS-Port-Type. . . . . . . . . . . . . . . . . . . . . . 12
+ 3.24. Port-Limit . . . . . . . . . . . . . . . . . . . . . . . 13
+ 3.25. Password-Retry . . . . . . . . . . . . . . . . . . . . . 13
+ 3.26. Connect-Info . . . . . . . . . . . . . . . . . . . . . . 13
+ 3.27. EAP-Message. . . . . . . . . . . . . . . . . . . . . . . 13
+ 3.28. Message-Authenticator. . . . . . . . . . . . . . . . . . 13
+ 3.29. NAS-Port-Id. . . . . . . . . . . . . . . . . . . . . . . 13
+ 3.30. Framed-Pool, Framed-IPv6-Pool. . . . . . . . . . . . . . 14
+ 3.31. Tunnel Attributes. . . . . . . . . . . . . . . . . . . . 14
+ 4. RC4 EAPOL-Key Descriptor . . . . . . . . . . . . . . . . . . . 15
+ 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 18
+ 5.1. Packet Modification or Forgery . . . . . . . . . . . . . 18
+ 5.2. Dictionary Attacks . . . . . . . . . . . . . . . . . . . 19
+ 5.3. Known Plaintext Attacks. . . . . . . . . . . . . . . . . 19
+ 5.4. Replay . . . . . . . . . . . . . . . . . . . . . . . . . 20
+ 5.5. Outcome Mismatches . . . . . . . . . . . . . . . . . . . 20
+
+
+
+Congdon, et al. Informational [Page 2]
+
+RFC 3580 IEEE 802.1X RADIUS September 2003
+
+
+ 5.6. 802.11 Integration . . . . . . . . . . . . . . . . . . . 20
+ 5.7. Key Management Issues. . . . . . . . . . . . . . . . . . 21
+ 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 22
+ 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
+ 7.1. Normative References . . . . . . . . . . . . . . . . . . 22
+ 7.2. Informative References . . . . . . . . . . . . . . . . . 23
+ 8. Table of Attributes. . . . . . . . . . . . . . . . . . . . . . 25
+ 9. Intellectual Property Statement . . . . . . . . . . . . . . . 28
+ 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
+ 11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29
+ 12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 30
+
+1. Introduction
+
+ IEEE 802.1X enables authenticated access to IEEE 802 media, including
+ Ethernet, Token Ring, and 802.11 wireless LANs. Although Remote
+ Authentication Dial In User Service (RADIUS) support is optional
+ within IEEE 802.1X, it is expected that many IEEE 802.1X
+ Authenticators will function as RADIUS clients.
+
+ IEEE 802.1X [IEEE8021X] provides "network port authentication" for
+ IEEE 802 [IEEE802] media, including Ethernet [IEEE8023], Token Ring
+ and 802.11 [IEEE80211] wireless LANS.
+
+ IEEE 802.1X does not require use of a backend Authentication Server,
+ and thus can be deployed with stand-alone bridges or Access Points,
+ as well as in centrally managed scenarios.
+
+ In situations where it is desirable to centrally manage
+ authentication, authorization and accounting (AAA) for IEEE 802
+ networks, deployment of a backend authentication and accounting
+ server is desirable. In such situations, it is expected that IEEE
+ 802.1X Authenticators will function as AAA clients.
+
+ This document provides suggestions on RADIUS usage by IEEE 802.1X
+ Authenticators. Support for any AAA protocol is optional for IEEE
+ 802.1X Authenticators, and therefore this specification has been
+ incorporated into a non-normative Appendix within the IEEE 802.1X
+ specification.
+
+1.1. Terminology
+
+ This document uses the following terms:
+
+ Access Point (AP)
+ A Station that provides access to the distribution services via
+ the wireless medium for associated Stations.
+
+
+
+
+Congdon, et al. Informational [Page 3]
+
+RFC 3580 IEEE 802.1X RADIUS September 2003
+
+
+ Association
+ The service used to establish Access Point/Station mapping and
+ enable Station invocation of the distribution system services.
+
+ Authenticator
+ An Authenticator is an entity that requires authentication from
+ the Supplicant. The Authenticator may be connected to the
+ Supplicant at the other end of a point-to-point LAN segment or
+ 802.11 wireless link.
+
+ Authentication Server
+ An Authentication Server is an entity that provides an
+ Authentication Service to an Authenticator. This service
+ verifies, from the credentials provided by the Supplicant, the
+ claim of identity made by the Supplicant.
+
+ Port Access Entity (PAE)
+ The protocol entity associated with a physical or virtual
+ (802.11) Port. A given PAE may support the protocol
+ functionality associated with the Authenticator, Supplicant or
+ both.
+
+ Station (STA)
+ Any device that contains an IEEE 802.11 conformant medium
+ access control (MAC) and physical layer (PHY) interface to the
+ wireless medium (WM).
+
+ Supplicant
+ A Supplicant is an entity that is being authenticated by an
+ Authenticator. The Supplicant may be connected to the
+ Authenticator at one end of a point-to-point LAN segment or
+ 802.11 wireless link.
+
+1.2. Requirements Language
+
+ 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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+Congdon, et al. Informational [Page 4]
+
+RFC 3580 IEEE 802.1X RADIUS September 2003
+
+
+2. RADIUS Accounting Attributes
+
+ With a few exceptions, the RADIUS accounting attributes defined in
+ [RFC2866], [RFC2867], and [RFC2869] have the same meaning within IEEE
+ 802.1X sessions as they do in dialup sessions and therefore no
+ additional commentary is needed.
+
+ Attributes requiring more discussion include:
+
+ Acct-Terminate-Cause
+ Acct-Multi-Session-Id
+ Acct-Link-Count
+
+2.1. Acct-Terminate-Cause
+
+ This attribute indicates how the session was terminated, as described
+ in [RFC2866]. [IEEE8021X] defines the following termination cause
+ values, which are shown with their RADIUS equivalents in the table on
+ the next page.
+
+ IEEE 802.1X RADIUS
+ dot1xAuthSessionTerminateCause Acct-Terminate-Cause
+ Value Value
+ ------------- --------------------
+ SupplicantLogoff(1) User Request (1)
+ portFailure(2) Lost Carrier (2)
+ SupplicantRestart(3) Supplicant Restart (19)
+ reauthFailed(4) Reauthentication Failure (20)
+ authControlForceUnauth(5) Admin Reset (6)
+ portReInit(6) Port Reinitialized (21)
+ portAdminDisabled(7) Port Administratively Disabled (22)
+ notTerminatedYet(999) N/A
+
+ When using this attribute, the User Request (1) termination cause
+ corresponds to the situation in which the session terminated due to
+ an EAPOL-Logoff received from the Supplicant. When a session is
+ moved due to roaming, the EAPOL state machines will treat this as a
+ Supplicant Logoff.
+
+ A Lost Carrier (2) termination cause indicates session termination
+ due to loss of physical connectivity for reasons other than roaming
+ between Access Points. For example, if the Supplicant disconnects a
+ point-to-point LAN connection, or moves out of range of an Access
+ Point, this termination cause is used. Lost Carrier (2) therefore
+ equates to a Port Disabled condition in the EAPOL state machines.
+
+ A Supplicant Restart (19) termination cause indicates
+ re-initialization of the Supplicant state machines.
+
+
+
+Congdon, et al. Informational [Page 5]
+
+RFC 3580 IEEE 802.1X RADIUS September 2003
+
+
+ A Reauthentication Failure (20) termination cause indicates that a
+ previously authenticated Supplicant has failed to re-authenticate
+ successfully following expiry of the re-authentication timer or
+ explicit re-authentication request by management action.
+
+ Within [IEEE80211], periodic re-authentication may be useful in
+ preventing reuse of an initialization vector with a given key. Since
+ successful re-authentication does not result in termination of the
+ session, accounting packets are not sent as a result of
+ re-authentication unless the status of the session changes. For
+ example:
+
+ a. The session is terminated due to re-authentication failure. In
+ this case the Reauthentication Failure (20) termination cause is
+ used.
+
+ b. The authorizations are changed as a result of a successful
+ re-authentication. In this case, the Service Unavailable (15)
+ termination cause is used. For accounting purposes, the portion
+ of the session after the authorization change is treated as a
+ separate session.
+
+ Where IEEE 802.1X authentication occurs prior to association,
+ accounting packets are not sent until an association occurs.
+
+ An Admin Reset (6) termination cause indicates that the Port has been
+ administratively forced into the unauthorized state.
+
+ A Port Reinitialized (21) termination cause indicates that the Port's
+ MAC has been reinitialized.
+
+ A Port Administratively Disabled (22) termination cause indicates
+ that the Port has been administratively disabled.
+
+2.2. Acct-Multi-Session-Id
+
+ The purpose of this attribute is to make it possible to link together
+ multiple related sessions. While [IEEE8021X] does not act on
+ aggregated ports, it is possible for a Supplicant roaming between
+ Access Points to cause multiple RADIUS accounting packets to be sent
+ by different Access Points.
+
+ Where supported by the Access Points, the Acct-Multi-Session-Id
+ attribute can be used to link together the multiple related sessions
+ of a roaming Supplicant. In such a situation, if the session context
+ is transferred between Access Points, accounting packets MAY be sent
+ without a corresponding authentication and authorization exchange,
+
+
+
+
+Congdon, et al. Informational [Page 6]
+
+RFC 3580 IEEE 802.1X RADIUS September 2003
+
+
+ provided that Association has occurred. However, in such a situation
+ it is assumed that the Acct-Multi-Session-Id is transferred between
+ the Access Points as part of the Inter-Access Point Protocol (IAPP).
+
+ If the Acct-Multi-Session-Id were not unique between Access Points,
+ then it is possible that the chosen Acct-Multi-Session-Id will
+ overlap with an existing value allocated on that Access Point, and
+ the Accounting Server would therefore be unable to distinguish a
+ roaming session from a multi-link session.
+
+ As a result, the Acct-Multi-Session-Id attribute is unique among all
+ the bridges or Access Points, Supplicants and sessions. In order to
+ provide this uniqueness, it is suggested that the Acct-Multi-
+ Session-Id be of the form:
+
+ Original AP MAC Address | Supplicant MAC Address | NTP Timestamp
+
+ Here "|" represents concatenation, the original AP MAC Address is the
+ MAC address of the bridge or Access Point at which the session
+ started, and the 64-bit NTP timestamp indicates the beginning of the
+ original session. In order to provide for consistency of the Acct-
+ Multi-Session-Id between roaming sessions, the Acct-Multi-Session-Id
+ may be moved between Access Points as part of IAPP or another handoff
+ scheme.
+
+ The use of an Acct-Multi-Session-Id of this form guarantees
+ uniqueness among all Access Points, Supplicants and sessions. Since
+ the NTP timestamp does not wrap on reboot, there is no possibility
+ that a rebooted Access Point could choose an Acct-Multi-Session-Id
+ that could be confused with that of a previous session.
+
+ Since the Acct-Multi-Session-Id is of type String as defined in
+ [RFC2866], for use with IEEE 802.1X, it is encoded as an ASCII string
+ of Hex digits. Example: "00-10-A4-23-19-C0-00-12-B2-
+ 14-23-DE-AF-23-83-C0-76-B8-44-E8"
+
+2.3. Acct-Link-Count
+
+ The Acct-Link-Count attribute may be used to account for the number
+ of ports that have been aggregated.
+
+3. RADIUS Authentication
+
+ This section describes how attributes defined in [RFC2865],
+ [RFC2867], [RFC2868], [RFC2869], [RFC3162] and [RFC3579] are used in
+ IEEE 802.1X authentication.
+
+
+
+
+
+Congdon, et al. Informational [Page 7]
+
+RFC 3580 IEEE 802.1X RADIUS September 2003
+
+
+3.1. User-Name
+
+ In IEEE 802.1X, the Supplicant typically provides its identity via an
+ EAP-Response/Identity message. Where available, the Supplicant
+ identity is included in the User-Name attribute, and included in the
+ RADIUS Access-Request and Access-Reply messages as specified in
+ [RFC2865] and [RFC3579].
+
+ Alternatively, as discussed in [RFC3579] Section 2.1., the User-Name
+ attribute may contain the Calling-Station-ID value, which is set to
+ the Supplicant MAC address.
+
+3.2. User-Password, CHAP-Password, CHAP-Challenge
+
+ Since IEEE 802.1X does not support PAP or CHAP authentication, the
+ User-Password, CHAP-Password or CHAP-Challenge attributes are not
+ used by IEEE 802.1X Authenticators acting as RADIUS clients.
+
+3.3. NAS-IP-Address, NAS-IPv6-Address
+
+ For use with IEEE 802.1X, the NAS-IP-Address contains the IPv4
+ address of the bridge or Access Point acting as an Authenticator, and
+ the NAS-IPv6-Address contains the IPv6 address. If the IEEE 802.1X
+ Authenticator has more than one interface, it may be desirable to use
+ a loopback address for this purpose so that the Authenticator will
+ still be reachable even if one of the interfaces were to fail.
+
+3.4. NAS-Port
+
+ For use with IEEE 802.1X the NAS-Port will contain the port number of
+ the bridge, if this is available. While an Access Point does not
+ have physical ports, a unique "association ID" is assigned to every
+ mobile Station upon a successful association exchange. As a result,
+ for an Access Point, if the association exchange has been completed
+ prior to authentication, the NAS-Port attribute will contain the
+ association ID, which is a 16-bit unsigned integer. Where IEEE
+ 802.1X authentication occurs prior to association, a unique NAS-Port
+ value may not be available.
+
+3.5. Service-Type
+
+ For use with IEEE 802.1X, the Framed (2), Authenticate Only (8), and
+ Call Check (10) values are most commonly used.
+
+ A Service-Type of Framed indicates that appropriate 802 framing
+ should be used for the connection. A Service-Type of Authenticate
+ Only (8) indicates that no authorization information needs to be
+ returned in the Access-Accept. As described in [RFC2865], a
+
+
+
+Congdon, et al. Informational [Page 8]
+
+RFC 3580 IEEE 802.1X RADIUS September 2003
+
+
+ Service-Type of Call Check is included in an Access-Request packet to
+ request that the RADIUS server accept or reject the connection
+ attempt, typically based on the Called-Station-ID (set to the bridge
+ or Access Point MAC address) or Calling-Station-ID attributes (set to
+ the Supplicant MAC address). As noted in [RFC2865], it is
+ recommended that in this case, the User-Name attribute be given the
+ value of Calling-Station-Id.
+
+3.6. Framed-Protocol
+
+ Since there is no value for IEEE 802 media, the Framed-Protocol
+ attribute is not used by IEEE 802.1X Authenticators.
+
+3.7. Framed-IP-Address, Framed-IP-Netmask
+
+ IEEE 802.1X does not provide a mechanism for IP address assignment.
+ Therefore the Framed-IP-Address and Framed-IP-Netmask attributes can
+ only be used by IEEE 802.1X Authenticators that support IP address
+ assignment mechanisms. Typically this capability is supported by
+ layer 3 devices.
+
+3.8. Framed-Routing
+
+ The Framed-Routing attribute indicates the routing method for the
+ Supplicant. It is therefore only relevant for IEEE 802.1X
+ Authenticators that act as layer 3 devices, and cannot be used by a
+ bridge or Access Point.
+
+3.9. Filter-ID
+
+ This attribute indicates the name of the filter list to be applied to
+ the Supplicant's session. For use with an IEEE 802.1X Authenticator,
+ it may be used to indicate either layer 2 or layer 3 filters. Layer
+ 3 filters are typically only supported on IEEE 802.1X Authenticators
+ that act as layer 3 devices.
+
+3.10. Framed-MTU
+
+ This attribute indicates the maximum size of an IP packet that may be
+ transmitted over the wire between the Supplicant and the
+ Authenticator. IEEE 802.1X Authenticators set this to the value
+ corresponding to the relevant 802 medium, and include it in the
+ RADIUS Access-Request. The RADIUS server may send an EAP packet as
+ large as Framed-MTU minus four (4) octets, taking into account the
+ additional overhead for the IEEE 802.1X Version (1), Type (1) and
+ Body Length (2) fields. For EAP over IEEE 802 media, the Framed-MTU
+ values (which do not include LLC/SNAP overhead) and maximum frame
+ length values (not including the preamble) are as follows:
+
+
+
+Congdon, et al. Informational [Page 9]
+
+RFC 3580 IEEE 802.1X RADIUS September 2003
+
+
+ Maximum Frame
+ Media Framed-MTU Length
+ ========= =============== ==============
+ Ethernet 1500 1522
+ 802.3 1500 1522
+ 802.4 8174 8193
+ 802.5 (4 Mbps) 4528 4550
+ 802.5 (16 Mbps) 18173 18200
+ 802.5 (100 Mb/s) 18173 18200
+ 802.6 9191 9240
+ 802.9a 1500 1518
+ 802.11 2304 2346
+ 802.12 (Ethernet) 1500 1518
+ 802.12 (Token Ring) 4502 4528
+ FDDI 4479 4500
+
+ NOTE - the Framed-MTU size for IEEE 802.11 media may change as a
+ result of ongoing work being undertaken in the IEEE 802.11 Working
+ Group. Since some 802.11 stations cannot handle an MTU larger than
+ 1500 octets, it is recommended that RADIUS servers encountering a
+ NAS-Port-Type value of 802.11 send EAP packets no larger than 1496
+ octets.
+
+3.11. Framed-Compression
+
+ [IEEE8021X] does not include compression support. Therefore this
+ attribute is not understood by [IEEE8021X] Authenticators.
+
+3.12. Displayable Messages
+
+ The Reply-Message attribute, defined in section 5.18 of [RFC2865],
+ indicates text which may be displayed to the user. This is similar
+ in concept to the EAP Notification Type, defined in [RFC2284]. As
+ noted in [RFC3579], Section 2.6.5, when sending a displayable message
+ to an [IEEE8021X] Authenticator, displayable messages are best sent
+ within EAP-Message/EAP-Request/Notification attribute(s), and not
+ within Reply-Message attribute(s).
+
+3.13. Callback-Number, Callback-ID
+
+ These attributes are not understood by IEEE 802.1X Authenticators.
+
+
+
+
+
+
+
+
+
+
+Congdon, et al. Informational [Page 10]
+
+RFC 3580 IEEE 802.1X RADIUS September 2003
+
+
+3.14. Framed-Route, Framed-IPv6-Route
+
+ The Framed-Route and Framed-IPv6-Route attributes provide routes that
+ are to be configured for the Supplicant. These attributes are
+ therefore only relevant for IEEE 802.1X Authenticators that act as
+ layer 3 devices, and cannot be understood by a bridge or Access
+ Point.
+
+3.15. State, Class, Proxy-State
+
+ These attributes are used for the same purposes as described in
+ [RFC2865].
+
+3.16. Vendor-Specific
+
+ Vendor-specific attributes are used for the same purposes as
+ described in [RFC2865]. The MS-MPPE-Send-Key and MS-MPPE-Recv-Key
+ attributes, described in section 2.4 of [RFC2548], MAY be used to
+ encrypt and authenticate the RC4 EAPOL-Key descriptor [IEEE8021X,
+ Section 7.6]. Examples of the derivation of the MS-MPPE-Send-Key and
+ MS-MPPE-Recv-Key attributes from the master key negotiated by an EAP
+ method are given in [RFC2716]. Details of the EAPOL-Key descriptor
+ are provided in Section 4.
+
+3.17. Session-Timeout
+
+ When sent along in an Access-Accept without a Termination-Action
+ attribute or with a Termination-Action attribute set to Default, the
+ Session-Timeout attribute specifies the maximum number of seconds of
+ service provided prior to session termination.
+
+ When sent in an Access-Accept along with a Termination-Action value
+ of RADIUS-Request, the Session-Timeout attribute specifies the
+ maximum number of seconds of service provided prior to re-
+ authentication. In this case, the Session-Timeout attribute is used
+ to load the reAuthPeriod constant within the Reauthentication Timer
+ state machine of 802.1X. When sent with a Termination-Action value
+ of RADIUS-Request, a Session-Timeout value of zero indicates the
+ desire to perform another authentication (possibly of a different
+ type) immediately after the first authentication has successfully
+ completed.
+
+ When sent in an Access-Challenge, this attribute represents the
+ maximum number of seconds that an IEEE 802.1X Authenticator should
+ wait for an EAP-Response before retransmitting. In this case, the
+ Session-Timeout attribute is used to load the suppTimeout constant
+ within the backend state machine of IEEE 802.1X.
+
+
+
+
+Congdon, et al. Informational [Page 11]
+
+RFC 3580 IEEE 802.1X RADIUS September 2003
+
+
+3.18. Idle-Timeout
+
+ The Idle-Timeout attribute is described in [RFC2865]. For IEEE 802
+ media other than 802.11 the media are always on. As a result the
+ Idle-Timeout attribute is typically only used with wireless media
+ such as IEEE 802.11. It is possible for a wireless device to wander
+ out of range of all Access Points. In this case, the Idle-Timeout
+ attribute indicates the maximum time that a wireless device may
+ remain idle.
+
+3.19. Termination-Action
+
+ This attribute indicates what action should be taken when the service
+ is completed. The value RADIUS-Request (1) indicates that re-
+ authentication should occur on expiration of the Session-Time. The
+ value Default (0) indicates that the session should terminate.
+
+3.20. Called-Station-Id
+
+ For IEEE 802.1X Authenticators, this attribute is used to store the
+ bridge or Access Point MAC address in ASCII format (upper case only),
+ with octet values separated by a "-". Example: "00-10-A4-23-19-C0".
+ In IEEE 802.11, where the SSID is known, it SHOULD be appended to the
+ Access Point MAC address, separated from the MAC address with a ":".
+ Example "00-10-A4-23-19-C0:AP1".
+
+3.21. Calling-Station-Id
+
+ For IEEE 802.1X Authenticators, this attribute is used to store the
+ Supplicant MAC address in ASCII format (upper case only), with octet
+ values separated by a "-". Example: "00-10-A4-23-19-C0".
+
+3.22. NAS-Identifier
+
+ This attribute contains a string identifying the IEEE 802.1X
+ Authenticator originating the Access-Request.
+
+3.23. NAS-Port-Type
+
+ For use with IEEE 802.1X, NAS-Port-Type values of Ethernet (15)
+ Wireless - IEEE 802.11 (19), Token Ring (20) and FDDI (21) may be
+ used.
+
+
+
+
+
+
+
+
+
+Congdon, et al. Informational [Page 12]
+
+RFC 3580 IEEE 802.1X RADIUS September 2003
+
+
+3.24. Port-Limit
+
+ This attribute has no meaning when sent to an [IEEE8021X]
+ Authenticator.
+
+3.25. Password-Retry
+
+ In IEEE 802.1X, the Authenticator always transitions to the HELD
+ state after an authentication failure. Thus this attribute does not
+ make sense for IEEE 802.1X.
+
+3.26. Connect-Info
+
+ This attribute is sent by a bridge or Access Point to indicate the
+ nature of the Supplicant's connection. When sent in the Access-
+ Request it is recommended that this attribute contain information on
+ the speed of the Supplicant's connection. For 802.11, the following
+ format is recommended: "CONNECT 11Mbps 802.11b". If sent in the
+ Accounting STOP, this attribute may be used to summarize statistics
+ relating to session quality. For example, in IEEE 802.11, the
+ Connect-Info attribute may contain information on the number of link
+ layer retransmissions. The exact format of this attribute is
+ implementation specific.
+
+3.27. EAP-Message
+
+ Since IEEE 802.1X provides for encapsulation of EAP as described in
+ [RFC2284] and [IEEE8021X], the EAP-Message attribute defined in
+ [RFC3579] is used to encapsulate EAP packets for transmission from
+ the IEEE 802.1X Authenticator to the Authentication Server. [RFC3579]
+ Section 2.2. describes how the Authentication Server handles invalid
+ EAP packets passed to it by the Authenticator.
+
+3.28. Message-Authenticator
+
+ As noted in [RFC3579] Section 3.1., the Message-Authenticator
+ attribute MUST be used to protect packets within a RADIUS/EAP
+ conversation.
+
+3.29. NAS-Port-Id
+
+ This attribute is used to identify the IEEE 802.1X Authenticator port
+ which authenticates the Supplicant. The NAS-Port-Id differs from the
+ NAS-Port in that it is a string of variable length whereas the NAS-
+ Port is a 4 octet value.
+
+
+
+
+
+
+Congdon, et al. Informational [Page 13]
+
+RFC 3580 IEEE 802.1X RADIUS September 2003
+
+
+3.30. Framed-Pool, Framed-IPv6-Pool
+
+ IEEE 802.1X does not provide a mechanism for IP address assignment.
+ Therefore the Framed-Pool and Framed-IPv6-Pool attributes can only be
+ used by IEEE 802.1X Authenticators that support IP address assignment
+ mechanisms. Typically this capability is supported by layer 3
+ devices.
+
+3.31. Tunnel Attributes
+
+ Reference [RFC2868] defines RADIUS tunnel attributes used for
+ authentication and authorization, and [RFC2867] defines tunnel
+ attributes used for accounting. Where the IEEE 802.1X Authenticator
+ supports tunneling, a compulsory tunnel may be set up for the
+ Supplicant as a result of the authentication.
+
+ In particular, it may be desirable to allow a port to be placed into
+ a particular Virtual LAN (VLAN), defined in [IEEE8021Q], based on the
+ result of the authentication. This can be used, for example, to
+ allow a wireless host to remain on the same VLAN as it moves within a
+ campus network.
+
+ The RADIUS server typically indicates the desired VLAN by including
+ tunnel attributes within the Access-Accept. However, the IEEE 802.1X
+ Authenticator may also provide a hint as to the VLAN to be assigned
+ to the Supplicant by including Tunnel attributes within the Access-
+ Request.
+
+ For use in VLAN assignment, the following tunnel attributes are used:
+
+ Tunnel-Type=VLAN (13)
+ Tunnel-Medium-Type=802
+ Tunnel-Private-Group-ID=VLANID
+
+ Note that the VLANID is 12-bits, taking a value between 1 and 4094,
+ inclusive. Since the Tunnel-Private-Group-ID is of type String as
+ defined in [RFC2868], for use with IEEE 802.1X, the VLANID integer
+ value is encoded as a string.
+
+ When Tunnel attributes are sent, it is necessary to fill in the Tag
+ field. As noted in [RFC2868], section 3.1:
+
+ The Tag field is one octet in length and is intended to provide a
+ means of grouping attributes in the same packet which refer to the
+ same tunnel. Valid values for this field are 0x01 through 0x1F,
+ inclusive. If the Tag field is unused, it MUST be zero (0x00).
+
+
+
+
+
+Congdon, et al. Informational [Page 14]
+
+RFC 3580 IEEE 802.1X RADIUS September 2003
+
+
+ For use with Tunnel-Client-Endpoint, Tunnel-Server-Endpoint, Tunnel-
+ Private-Group-ID, Tunnel-Assignment-ID, Tunnel-Client-Auth-ID or
+ Tunnel-Server-Auth-ID attributes (but not Tunnel-Type, Tunnel-
+ Medium-Type, Tunnel-Password, or Tunnel-Preference), a tag field of
+ greater than 0x1F is interpreted as the first octet of the following
+ field.
+
+ Unless alternative tunnel types are provided, (e.g. for IEEE 802.1X
+ Authenticators that may support tunneling but not VLANs), it is only
+ necessary for tunnel attributes to specify a single tunnel. As a
+ result, where it is only desired to specify the VLANID, the tag field
+ SHOULD be set to zero (0x00) in all tunnel attributes. Where
+ alternative tunnel types are to be provided, tag values between 0x01
+ and 0x1F SHOULD be chosen.
+
+4. RC4 EAPOL-Key Frame
+
+ The RC4 EAPOL-Key frame is created and transmitted by the
+ Authenticator in order to provide media specific key information.
+ For example, within 802.11 the RC4 EAPOL-Key frame can be used to
+ distribute multicast/broadcast ("default") keys, or unicast ("key
+ mapping") keys. The "default" key is the same for all Stations
+ within a broadcast domain.
+
+ The RC4 EAPOL-Key frame is not acknowledged and therefore the
+ Authenticator does not know whether the Supplicant has received it.
+ If it is lost, then the Supplicant and Authenticator will not have
+ the same keying material, and communication will fail. If this
+ occurs, the problem is typically addressed by re-running the
+ authentication.
+
+ The RC4 EAPOL-Key frame is sent from the Authenticator to the
+ Supplicant in order to provision the "default" key, and subsequently
+ in order to refresh the "default" key. It may also be used to
+ refresh the key-mapping key. Rekey is typically only required with
+ weak ciphersuites such as WEP, defined in [IEEE80211].
+
+ Where keys are required, an EAP method that derives keys is typically
+ selected. Therefore the initial "key mapping" keys can be derived
+ from EAP keying material, without requiring the Authenticator to send
+ an RC4 EAPOL-Key frame to the Supplicant. An example of how EAP
+ keying material can be derived and used is presented in [RFC2716].
+
+
+
+
+
+
+
+
+
+Congdon, et al. Informational [Page 15]
+
+RFC 3580 IEEE 802.1X RADIUS September 2003
+
+
+ While the RC4 EAPOL-Key frame is defined in [IEEE8021X], a more
+ complete description is provided on the next page.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Version | Packet Type | Packet Body Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Key Length |Replay Counter...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Replay Counter...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Replay Counter | Key IV...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Key IV...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Key IV...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Key IV...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Key IV... |F| Key Index |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Key Signature...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Key Signature...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Key Signature...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Key Signature...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Key...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Version
+ The Version field is one octet. For IEEE 802.1X, it contains the
+ value 0x01.
+
+ Packet Type
+ The Packet Type field is one octet, and determines the type of
+ packet being transmitted. For an EAPOL-Key Descriptor, the Packet
+ Type field contains 0x03.
+
+ Packet Body Length
+ The Packet Body Length is two octets, and contains the length of
+ the EAPOL-Key descriptor in octets, not including the Version,
+ Packet Type and Packet Body Length fields.
+
+
+
+
+
+Congdon, et al. Informational [Page 16]
+
+RFC 3580 IEEE 802.1X RADIUS September 2003
+
+
+ Type
+ The Type field is a single octet. The Key descriptor is defined
+ differently for each Type; this specification documents only the
+ RC4 Key Descriptor (Type = 0x01).
+
+ Key Length
+ The Key Length field is two octets. If Packet Body Length = 44 +
+ Key Length, then the Key Field contains the key in encrypted form,
+ of length Key Length. This is 5 octets (40 bits) for WEP, and 13
+ octets (104 bits) for WEP-128. If Packet Body Length = 44, then
+ the Key field is absent, and Key Length represents the number of
+ least significant octets from the MS-MPPE-Send-Key attribute
+ [RFC2548] to be used as the keying material. Note that the MS-
+ MPPE-Send-Key and MS-MPPE-Recv-Key attributes are defined from the
+ point of view of the Authenticator. From the Supplicant point of
+ reference, the terms are reversed. Thus the MS-MPPE-Recv-Key on
+ the Supplicant corresponds to the MS-MPPE-Send-Key on the
+ Authenticator, and the MS-MPPE-Send-Key on the Supplicant
+ corresponds to the MS-MPPE-Recv-Key on the Authenticator.
+
+ Replay Counter
+ The Replay Counter field is 8 octets. It does not repeat within
+ the life of the keying material used to encrypt the Key field and
+ compute the Key Signature field. A 64-bit NTP timestamp MAY be
+ used as the Replay Counter.
+
+ Key IV
+ The Key IV field is 16 octets and includes a 128-bit
+ cryptographically random number.
+
+ F
+ The Key flag (F) is a single bit, describing the type of key that
+ is included in the Key field. Values are:
+
+ 0 = for broadcast (default key)
+ 1 = for unicast (key mapping key)
+
+ Key Index
+ The Key Index is 7 bits.
+
+ Key Signature
+ The Key Signature field is 16 octets. It contains an HMAC-MD5
+ message integrity check computed over the EAPOL-Key descriptor,
+ starting from the Version field, with the Key field filled in if
+ present, but with the Key Signature field set to zero. For the
+ computation, the 32 octet (256 bit) MS-MPPE-Send-Key [RFC2548] is
+ used as the HMAC-MD5 key.
+
+
+
+
+Congdon, et al. Informational [Page 17]
+
+RFC 3580 IEEE 802.1X RADIUS September 2003
+
+
+ Key
+ If Packet Body Length = 44 + Key Length, then the Key Field
+ contains the key in encrypted form, of length Key Length. If
+ Packet Body Length = 44, then the Key field is absent, and the
+ least significant Key Length octets from the MS-MPPE-Send-Key
+ attribute is used as the keying material. Where the Key field is
+ encrypted using RC4, the RC4 encryption key used to encrypt this
+ field is formed by concatenating the 16 octet (128 bit) Key-IV
+ field with the 32 octet MS-MPPE-Recv-Key attribute. This yields a
+ 48 octet RC4 key (384 bits).
+
+5. Security Considerations
+
+ Since this document describes the use of RADIUS for purposes of
+ authentication, authorization, and accounting in IEEE 802.1X-enabled
+ networks, it is vulnerable to all of the threats that are present in
+ other RADIUS applications. For a discussion of these threats, see
+ [RFC2607], [RFC2865], [RFC3162], [RFC3579], and [RFC3576].
+
+ Vulnerabilities include:
+
+ Packet modification or forgery
+ Dictionary attacks
+ Known plaintext attacks
+ Replay
+ Outcome mismatches
+ 802.11 integration
+ Key management issues
+
+5.1. Packet Modification or Forgery
+
+ RADIUS, defined in [RFC2865], does not require all Access-Requests to
+ be authenticated or integrity protected. However, IEEE 802.1X is
+ based on EAP. As described in [3579], Section 3.1.:
+
+ The Message-Authenticator attribute MUST be used to protect all
+ Access-Request, Access-Challenge, Access-Accept, and Access-Reject
+ packets containing an EAP-Message attribute.
+
+ As a result, when used with IEEE 802.1X, all RADIUS packets MUST be
+ authenticated and integrity protected. In addition, as described in
+ [3579], Section 4.2.:
+
+ To address the security vulnerabilities of RADIUS/EAP,
+ implementations of this specification SHOULD support IPsec
+ [RFC2401] along with IKE [RFC2409] for key management. IPsec ESP
+ [RFC2406] with non-null transform SHOULD be supported, and IPsec
+ ESP with a non-null encryption transform and authentication
+
+
+
+Congdon, et al. Informational [Page 18]
+
+RFC 3580 IEEE 802.1X RADIUS September 2003
+
+
+ support SHOULD be used to provide per-packet confidentiality,
+ authentication, integrity and replay protection. IKE SHOULD be
+ used for key management.
+
+5.2. Dictionary Attacks
+
+ As discussed in [RFC3579] Section 4.3.3., the RADIUS shared secret is
+ vulnerable to offline dictionary attack, based on capture of the
+ Response Authenticator or Message-Authenticator attribute. In order
+ to decrease the level of vulnerability, [RFC2865], Section 3
+ recommends:
+
+ The secret (password shared between the client and the RADIUS
+ server) SHOULD be at least as large and unguessable as a well-
+ chosen password. It is preferred that the secret be at least 16
+ octets.
+
+ In addition, the risk of an offline dictionary attack can be further
+ mitigated by employing IPsec ESP with a non-null transform in order
+ to encrypt the RADIUS conversation, as described in [RFC3579],
+ Section 4.2.
+
+5.3. Known Plaintext Attacks
+
+ Since IEEE 802.1X is based on EAP, which does not support PAP, the
+ RADIUS User-Password attribute is not used to carry hidden user
+ passwords. The hiding mechanism utilizes MD5, defined in [RFC1321],
+ in order to generate a key stream based on the RADIUS shared secret
+ and the Request Authenticator. Where PAP is in use, it is possible
+ to collect key streams corresponding to a given Request Authenticator
+ value, by capturing RADIUS conversations corresponding to a PAP
+ authentication attempt using a known password. Since the User-
+ Password is known, the key stream corresponding to a given Request
+ Authenticator can be determined and stored.
+
+ The vulnerability is described in detail in [RFC3579], Section 4.3.4.
+ Even though IEEE 802.1X Authenticators do not support PAP
+ authentication, a security vulnerability can still exist where the
+ same RADIUS shared secret is used for hiding User-Password as well as
+ other attributes. This can occur, for example, if the same RADIUS
+ proxy handles authentication requests for both IEEE 802.1X (which may
+ hide the Tunnel-Password, MS-MPPE-Send-Key and MS-MPPE-Recv-Key
+ attributes) and GPRS (which may hide the User-Password attribute).
+
+ The threat can be mitigated by protecting RADIUS with IPsec ESP with
+ a non-null transform, as described in [RFC3579], Section 4.2. In
+ addition, the same RADIUS shared secret MUST NOT be used for both
+ IEEE 802.1X authentication and PAP authentication.
+
+
+
+Congdon, et al. Informational [Page 19]
+
+RFC 3580 IEEE 802.1X RADIUS September 2003
+
+
+5.4. Replay
+
+ As noted in [RFC3579] Section 4.3.5., the RADIUS protocol provides
+ only limited support for replay protection. Replay protection for
+ RADIUS authentication and accounting can be provided by enabling
+ IPsec replay protection with RADIUS, as described in [RFC3579],
+ Section 4.2.
+
+ As with the Request Authenticator, for use with IEEE 802.1X
+ Authenticators, the Acct-Session-Id SHOULD be globally and temporally
+ unique.
+
+5.5. Outcome Mismatches
+
+ [RFC3579] Section 2.6.3. discusses the issues that arise when the EAP
+ packet encapsulated in an EAP-Message attribute does not agree with
+ the RADIUS Packet Type. For example, an EAP Success packet might be
+ encapsulated within an Access-Reject; an EAP Failure might be sent
+ within an Access-Accept; or an EAP Success or Failure might be sent
+ within an Access-Challenge.
+
+ As described in [RFC3579] Section 2.6.3., these conflicting messages
+ are likely to cause confusion. To ensure that access decisions made
+ by IEEE 802.1X Authenticators conform to the wishes of the RADIUS
+ server, it is necessary for the Authenticator to make the decision
+ solely based on the authentication result (Access-Accept/Reject) and
+ not based on the contents of EAP-Message attributes, if present.
+
+5.6. 802.11 Integration
+
+ [IEEE8021X] was developed for use on wired IEEE 802 networks such as
+ Ethernet, and therefore does not describe how to securely adapt IEEE
+ 802.1X for use with 802.11. This is left to an enhanced security
+ specification under development within IEEE 802.11.
+
+ For example, [IEEE8021X] does not specify whether authentication
+ occurs prior to, or after association, nor how the derived keys are
+ used within various ciphersuites. It also does not specify
+ ciphersuites addressing the vulnerabilities discovered in WEP,
+ described in [Berkeley], [Arbaugh], [Fluhrer], and [Stubbl].
+ [IEEE8021X] only defines an authentication framework, leaving the
+ definition of the authentication methods to other documents, such as
+ [RFC2716].
+
+ Since [IEEE8021X] does not address 802.11 integration issues,
+ implementors are strongly advised to consult additional IEEE 802.11
+ security specifications for guidance on how to adapt IEEE 802.1X for
+ use with 802.11. For example, it is likely that the IEEE 802.11
+
+
+
+Congdon, et al. Informational [Page 20]
+
+RFC 3580 IEEE 802.1X RADIUS September 2003
+
+
+ enhanced security specification will define its own IEEE 802.11 key
+ hierarchy as well as new EAPOL-Key descriptors.
+
+5.7. Key Management Issues
+
+ The EAPOL-Key descriptor described in Section 4. is likely to be
+ deprecated in the future, when the IEEE 802.11 enhanced security
+ group completes its work. Known security issues include:
+
+ [1] Default key-only support. IEEE 802.1X enables the derivation of
+ per-Station unicast keys, known in [IEEE80211] as "key mapping
+ keys." Keys used to encrypt multicast/broadcast traffic are
+ known as "default keys". However, in some 802.11
+ implementations, the unicast keys, derived as part of the EAP
+ authentication process, are used solely in order to encrypt,
+ authenticate and integrity protect the EAPOL-Key descriptor, as
+ described in Section 4. These implementations only support use
+ of default keys (ordinarily only used with multicast/broadcast
+ traffic) to secure all traffic, unicast or multicast/broadcast,
+ resulting in inherent security weaknesses.
+
+ Where per-Station key-mapping keys (e.g. unicast keys) are
+ unsupported, any Station possessing the default key can decrypt
+ traffic from other Stations or impersonate them. When used
+ along with a weak cipher (e.g. WEP), implementations supporting
+ only default keys provide more material for attacks such as
+ those described in [Fluhrer] and [Stubbl]. If in addition, the
+ default key is not refreshed periodically, IEEE 802.1X dynamic
+ key derivation provides little or no security benefit. For an
+ understanding of the issues with WEP, see [Berkeley], [Arbaugh],
+ [Fluhrer], and [Stubbl].
+
+ [2] Reuse of keying material. The EAPOL-Key descriptor specified in
+ section 4 uses the same keying material (MS-MPPE-Recv-Key) both
+ to encrypt the Key field within the EAPOL-Key descriptor, and to
+ encrypt data passed between the Station and Access Point.
+ Multi-purpose keying material is frowned upon, since multiple
+ uses can leak information helpful to an attacker.
+
+ [3] Weak algorithms. The algorithm used to encrypt the Key field
+ within the EAPOL-Key descriptor is similar to the algorithm used
+ in WEP, and as a result, shares some of the same weaknesses. As
+ with WEP, the RC4 stream cipher is used to encrypt the key. As
+ input to the RC4 engine, the IV and key are concatenated rather
+ than being combined within a mixing function. As with WEP, the
+ IV is not a counter, and therefore there is little protection
+ against reuse.
+
+
+
+
+Congdon, et al. Informational [Page 21]
+
+RFC 3580 IEEE 802.1X RADIUS September 2003
+
+
+ As a result of these vulnerabilities, implementors intending to use
+ the EAPOL-Key descriptor described in this document are urged to
+ consult the 802.11 enhanced security specification for a more secure
+ alternative. It is also advisable to consult the evolving literature
+ on WEP vulnerabilities, in order to better understand the risks, as
+ well as to obtain guidance on setting an appropriate re-keying
+ interval.
+
+6. IANA Considerations
+
+ This specification does not create any RADIUS attributes nor any new
+ number spaces for IANA administration. However, it does require
+ assignment of new values to existing RADIUS attributes. These
+ include:
+
+ Attribute Values Required
+ ========= ===============
+ NAS-Port-Type Token-Ring (20), FDDI (21)
+ Tunnel-Type VLAN (13)
+ Acct-Terminate-Cause Supplicant Restart (19)
+ Reauthentication Failure (20)
+ Port Reinitialized (21)
+ Port Administratively Disabled (22)
+
+7. References
+
+7.1. Normative References
+
+ [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC
+ 1321, April 1992.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible
+ Authentication Protocol (EAP)", RFC 2284, March 1998.
+
+ [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson,
+ "Remote Authentication Dial In User Service (RADIUS)",
+ RFC 2865, June 2000.
+
+ [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
+
+ [RFC2867] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting
+ Modifications for Tunnel Protocol Support", RFC 2867,
+ June 2000.
+
+
+
+
+
+Congdon, et al. Informational [Page 22]
+
+RFC 3580 IEEE 802.1X RADIUS September 2003
+
+
+ [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J.,
+ Holdrege, M. and I. Goyret, "RADIUS Attributes for
+ Tunnel Protocol Support", RFC 2868, June 2000.
+
+ [RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS
+ Extensions", RFC 2869, June 2000.
+
+ [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6",
+ RFC 3162, August 2001.
+
+ [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
+ X.509 Public Key Infrastructure Certificate and
+ Certificate Revocation List (CRL) Profile", RFC 3280,
+ April 2002.
+
+ [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B.
+ Aboba, "Dynamic Authorization Extensions to Remote
+ Authentication Dial In User Service (RADIUS)", RFC
+ 3576, July 2003.
+
+ [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote
+ Authentication Dial In User Service) Support For
+ Extensible Authentication Protocol (EAP)", RFC 3579,
+ September 2003.
+
+ [IEEE8021X] IEEE Standards for Local and Metropolitan Area
+ Networks: Port based Network Access Control, IEEE Std
+ 802.1X-2001, June 2001.
+
+7.2. Informative References
+
+ [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
+ Keyed-Hashing for Message Authentication", RFC 2104,
+ February 1997.
+
+ [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
+ an IANA Considerations Section in RFCs", BCP 26, RFC
+ 2434, October 1998.
+
+ [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS
+ Attributes", RFC 2548, March 1999.
+
+ [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and
+ Policy Implementation in Roaming", RFC 2607, June
+ 1999.
+
+ [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication
+ Protocol", RFC 2716, October 1999.
+
+
+
+Congdon, et al. Informational [Page 23]
+
+RFC 3580 IEEE 802.1X RADIUS September 2003
+
+
+ [MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent
+ Attack." CryptoBytes Vol.2 No.2, Summer 1996.
+
+ [IEEE802] IEEE Standards for Local and Metropolitan Area
+ Networks: Overview and Architecture, ANSI/IEEE Std
+ 802, 1990.
+
+ [IEEE8021Q] IEEE Standards for Local and Metropolitan Area
+ Networks: Draft Standard for Virtual Bridged Local
+ Area Networks, P802.1Q, January 1998.
+
+ [IEEE8023] ISO/IEC 8802-3 Information technology -
+ Telecommunications and information exchange between
+ systems - Local and metropolitan area networks -
+ Common specifications - Part 3: Carrier Sense
+ Multiple Access with Collision Detection (CSMA/CD)
+ Access Method and Physical Layer Specifications, (also
+ ANSI/IEEE Std 802.3- 1996), 1996.
+
+ [IEEE80211] Information technology - Telecommunications and
+ information exchange between systems - Local and
+ metropolitan area networks - Specific Requirements
+ Part 11: Wireless LAN Medium Access Control (MAC) and
+ Physical Layer (PHY) Specifications, IEEE Std.
+ 802.11-1999, 1999.
+
+ [Berkeley] Borisov, N., Goldberg, I. and D. Wagner, "Intercepting
+ Mobile Communications: The Insecurity of 802.11", ACM
+ SIGMOBILE, Seventh Annual International Conference on
+ Mobile Computing and Networking, July 2001, Rome,
+ Italy.
+
+ [Arbaugh] Arbaugh, W., Shankar, N. and J.Y.C. Wan, "Your 802.11
+ Wireless Network has No Clothes", Department of
+ Computer Science, University of Maryland, College
+ Park, March 2001.
+
+ [Fluhrer] Fluhrer, S., Mantin, I. and A. Shamir, "Weaknesses in
+ the Key Scheduling Algorithm of RC4", Eighth Annual
+ Workshop on Selected Areas in Cryptography, Toronto,
+ Canada, August 2001.
+
+ [Stubbl] Stubblefield, A., Ioannidis, J. and A. Rubin, "Using
+ the Fluhrer, Mantin and Shamir Attack to Break WEP",
+ 2002 NDSS Conference.
+
+
+
+
+
+
+Congdon, et al. Informational [Page 24]
+
+RFC 3580 IEEE 802.1X RADIUS September 2003
+
+
+8. Table of Attributes
+
+ The following table provides a guide to which attributes MAY be sent
+ and received as part of IEEE 802.1X authentication. L3 denotes
+ attributes that require layer 3 capabilities, and thus may not be
+ supported by all Authenticators. For each attribute, the reference
+ provides the definitive information on usage.
+
+ 802.1X # Attribute
+ X 1 User-Name [RFC2865]
+ 2 User-Password [RFC2865]
+ 3 CHAP-Password [RFC2865]
+ X 4 NAS-IP-Address [RFC2865]
+ X 5 NAS-Port [RFC2865]
+ X 6 Service-Type [RFC2865]
+ 7 Framed-Protocol [RFC2865]
+ L3 8 Framed-IP-Address [RFC2865]
+ L3 9 Framed-IP-Netmask [RFC2865]
+ L3 10 Framed-Routing [RFC2865]
+ X 11 Filter-Id [RFC2865]
+ X 12 Framed-MTU [RFC2865]
+ 13 Framed-Compression [RFC2865]
+ L3 14 Login-IP-Host [RFC2865]
+ L3 15 Login-Service [RFC2865]
+ L3 16 Login-TCP-Port [RFC2865]
+ 18 Reply-Message [RFC2865]
+ 19 Callback-Number [RFC2865]
+ 20 Callback-Id [RFC2865]
+ L3 22 Framed-Route [RFC2865]
+ L3 23 Framed-IPX-Network [RFC2865]
+ X 24 State [RFC2865]
+ X 25 Class [RFC2865]
+ X 26 Vendor-Specific [RFC2865]
+ X 27 Session-Timeout [RFC2865]
+ X 28 Idle-Timeout [RFC2865]
+ X 29 Termination-Action [RFC2865]
+ X 30 Called-Station-Id [RFC2865]
+ X 31 Calling-Station-Id [RFC2865]
+ X 32 NAS-Identifier [RFC2865]
+ X 33 Proxy-State [RFC2865]
+ 34 Login-LAT-Service [RFC2865]
+ 35 Login-LAT-Node [RFC2865]
+ 36 Login-LAT-Group [RFC2865]
+ 802.1X # Attribute
+
+
+
+
+
+
+
+Congdon, et al. Informational [Page 25]
+
+RFC 3580 IEEE 802.1X RADIUS September 2003
+
+
+ 802.1X # Attribute
+ L3 37 Framed-AppleTalk-Link [RFC2865]
+ L3 38 Framed-AppleTalk-Network [RFC2865]
+ L3 39 Framed-AppleTalk-Zone [RFC2865]
+ X 40 Acct-Status-Type [RFC2866]
+ X 41 Acct-Delay-Time [RFC2866]
+ X 42 Acct-Input-Octets [RFC2866]
+ X 43 Acct-Output-Octets [RFC2866]
+ X 44 Acct-Session-Id [RFC2866]
+ X 45 Acct-Authentic [RFC2866]
+ X 46 Acct-Session-Time [RFC2866]
+ X 47 Acct-Input-Packets [RFC2866]
+ X 48 Acct-Output-Packets [RFC2866]
+ X 49 Acct-Terminate-Cause [RFC2866]
+ X 50 Acct-Multi-Session-Id [RFC2866]
+ X 51 Acct-Link-Count [RFC2866]
+ X 52 Acct-Input-Gigawords [RFC2869]
+ X 53 Acct-Output-Gigawords [RFC2869]
+ X 55 Event-Timestamp [RFC2869]
+ 60 CHAP-Challenge [RFC2865]
+ X 61 NAS-Port-Type [RFC2865]
+ 62 Port-Limit [RFC2865]
+ 63 Login-LAT-Port [RFC2865]
+ X 64 Tunnel-Type [RFC2868]
+ X 65 Tunnel-Medium-Type [RFC2868]
+ L3 66 Tunnel-Client-Endpoint [RFC2868]
+ L3 67 Tunnel-Server-Endpoint [RFC2868]
+ L3 68 Acct-Tunnel-Connection [RFC2867]
+ L3 69 Tunnel-Password [RFC2868]
+ 70 ARAP-Password [RFC2869]
+ 71 ARAP-Features [RFC2869]
+ 72 ARAP-Zone-Access [RFC2869]
+ 73 ARAP-Security [RFC2869]
+ 74 ARAP-Security-Data [RFC2869]
+ 75 Password-Retry [RFC2869]
+ 76 Prompt [RFC2869]
+ X 77 Connect-Info [RFC2869]
+ X 78 Configuration-Token [RFC2869]
+ X 79 EAP-Message [RFC3579]
+ X 80 Message-Authenticator [RFC3579]
+ X 81 Tunnel-Private-Group-ID [RFC2868]
+ L3 82 Tunnel-Assignment-ID [RFC2868]
+ X 83 Tunnel-Preference [RFC2868]
+ 84 ARAP-Challenge-Response [RFC2869]
+ 802.1X # Attribute
+
+
+
+
+
+
+Congdon, et al. Informational [Page 26]
+
+RFC 3580 IEEE 802.1X RADIUS September 2003
+
+
+ 802.1X # Attribute
+ X 85 Acct-Interim-Interval [RFC2869]
+ X 86 Acct-Tunnel-Packets-Lost [RFC2867]
+ X 87 NAS-Port-Id [RFC2869]
+ L3 88 Framed-Pool [RFC2869]
+ L3 90 Tunnel-Client-Auth-ID [RFC2868]
+ L3 91 Tunnel-Server-Auth-ID [RFC2868]
+ X 95 NAS-IPv6-Address [RFC3162]
+ 96 Framed-Interface-Id [RFC3162]
+ L3 97 Framed-IPv6-Prefix [RFC3162]
+ L3 98 Login-IPv6-Host [RFC3162]
+ L3 99 Framed-IPv6-Route [RFC3162]
+ L3 100 Framed-IPv6-Pool [RFC3162]
+ X 101 Error-Cause [RFC3576]
+ 802.1X # Attribute
+
+ Key
+ ===
+ X = May be used with IEEE 802.1X authentication
+ L3 = Implemented only by Authenticators with Layer 3
+ capabilities
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Congdon, et al. Informational [Page 27]
+
+RFC 3580 IEEE 802.1X RADIUS September 2003
+
+
+9. Intellectual Property Statement
+
+ 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.
+
+10. Acknowledgments
+
+ The authors would like to acknowledge Bob O'Hara of Airespace, David
+ Halasz of Cisco, Tim Moore, Sachin Seth and Ashwin Palekar of
+ Microsoft, Andrea Li, Albert Young and Dave Bagby of 3Com for
+ contributions to this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Congdon, et al. Informational [Page 28]
+
+RFC 3580 IEEE 802.1X RADIUS September 2003
+
+
+11. Authors' Addresses
+
+ Paul Congdon
+ Hewlett Packard Company
+ HP ProCurve Networking
+ 8000 Foothills Blvd, M/S 5662
+ Roseville, CA 95747
+
+ Phone: +1 916 785 5753
+ Fax: +1 916 785 8478
+ EMail: paul_congdon@hp.com
+
+ Bernard Aboba
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052
+
+ Phone: +1 425 706 6605
+ Fax: +1 425 936 7329
+ EMail: bernarda@microsoft.com
+
+ Andrew Smith
+ Trapeze Networks
+ 5753 W. Las Positas Blvd.
+ Pleasanton, CA 94588-4084
+
+ Fax: +1 415 345 1827
+ EMail: ah_smith@acm.org
+
+ John Roese
+ Enterasys
+
+ Phone: +1 603 337 1506
+ EMail: jjr@enterasys.com
+
+ Glen Zorn
+ Cisco Systems, Inc.
+ 500 108th Avenue N.E., Suite 500
+ Bellevue, WA 98004
+
+ Phone: +1 425 438 8218
+ Fax: +1 425 438 1848
+ EMail: gwz@cisco.com
+
+
+
+
+
+
+
+
+Congdon, et al. Informational [Page 29]
+
+RFC 3580 IEEE 802.1X RADIUS September 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Congdon, et al. Informational [Page 30]
+
diff --git a/rfc/rfc791.txt b/rfc/rfc791.txt
new file mode 100644
index 0000000..5952d0b
--- /dev/null
+++ b/rfc/rfc791.txt
@@ -0,0 +1,2887 @@
+
+
+RFC: 791
+
+
+
+
+
+
+
+ INTERNET PROTOCOL
+
+
+ DARPA INTERNET PROGRAM
+
+ PROTOCOL SPECIFICATION
+
+
+
+ September 1981
+
+
+
+
+
+
+
+
+
+
+
+
+
+ prepared for
+
+ Defense Advanced Research Projects Agency
+ Information Processing Techniques Office
+ 1400 Wilson Boulevard
+ Arlington, Virginia 22209
+
+
+
+
+
+
+
+ by
+
+ Information Sciences Institute
+ University of Southern California
+ 4676 Admiralty Way
+ Marina del Rey, California 90291
+
+
+
+September 1981
+ Internet Protocol
+
+
+
+ TABLE OF CONTENTS
+
+ PREFACE ........................................................ iii
+
+1. INTRODUCTION ..................................................... 1
+
+ 1.1 Motivation .................................................... 1
+ 1.2 Scope ......................................................... 1
+ 1.3 Interfaces .................................................... 1
+ 1.4 Operation ..................................................... 2
+
+2. OVERVIEW ......................................................... 5
+
+ 2.1 Relation to Other Protocols ................................... 9
+ 2.2 Model of Operation ............................................ 5
+ 2.3 Function Description .......................................... 7
+ 2.4 Gateways ...................................................... 9
+
+3. SPECIFICATION ................................................... 11
+
+ 3.1 Internet Header Format ....................................... 11
+ 3.2 Discussion ................................................... 23
+ 3.3 Interfaces ................................................... 31
+
+APPENDIX A: Examples & Scenarios ................................... 34
+APPENDIX B: Data Transmission Order ................................ 39
+
+GLOSSARY ............................................................ 41
+
+REFERENCES .......................................................... 45
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [Page i]
+
+
+ September 1981
+Internet Protocol
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page ii]
+
+
+September 1981
+ Internet Protocol
+
+
+
+ PREFACE
+
+
+
+This document specifies the DoD Standard Internet Protocol. This
+document is based on six earlier editions of the ARPA Internet Protocol
+Specification, and the present text draws heavily from them. There have
+been many contributors to this work both in terms of concepts and in
+terms of text. This edition revises aspects of addressing, error
+handling, option codes, and the security, precedence, compartments, and
+handling restriction features of the internet protocol.
+
+ Jon Postel
+
+ Editor
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [Page iii]
+
+
+
+ September 1981
+
+
+RFC: 791
+Replaces: RFC 760
+IENs 128, 123, 111,
+80, 54, 44, 41, 28, 26
+
+ INTERNET PROTOCOL
+
+ DARPA INTERNET PROGRAM
+ PROTOCOL SPECIFICATION
+
+
+
+ 1. INTRODUCTION
+
+1.1. Motivation
+
+ The Internet Protocol is designed for use in interconnected systems of
+ packet-switched computer communication networks. Such a system has
+ been called a "catenet" [1]. The internet protocol provides for
+ transmitting blocks of data called datagrams from sources to
+ destinations, where sources and destinations are hosts identified by
+ fixed length addresses. The internet protocol also provides for
+ fragmentation and reassembly of long datagrams, if necessary, for
+ transmission through "small packet" networks.
+
+1.2. Scope
+
+ The internet protocol is specifically limited in scope to provide the
+ functions necessary to deliver a package of bits (an internet
+ datagram) from a source to a destination over an interconnected system
+ of networks. There are no mechanisms to augment end-to-end data
+ reliability, flow control, sequencing, or other services commonly
+ found in host-to-host protocols. The internet protocol can capitalize
+ on the services of its supporting networks to provide various types
+ and qualities of service.
+
+1.3. Interfaces
+
+ This protocol is called on by host-to-host protocols in an internet
+ environment. This protocol calls on local network protocols to carry
+ the internet datagram to the next gateway or destination host.
+
+ For example, a TCP module would call on the internet module to take a
+ TCP segment (including the TCP header and user data) as the data
+ portion of an internet datagram. The TCP module would provide the
+ addresses and other parameters in the internet header to the internet
+ module as arguments of the call. The internet module would then
+ create an internet datagram and call on the local network interface to
+ transmit the internet datagram.
+
+ In the ARPANET case, for example, the internet module would call on a
+
+
+ [Page 1]
+
+
+ September 1981
+Internet Protocol
+Introduction
+
+
+
+ local net module which would add the 1822 leader [2] to the internet
+ datagram creating an ARPANET message to transmit to the IMP. The
+ ARPANET address would be derived from the internet address by the
+ local network interface and would be the address of some host in the
+ ARPANET, that host might be a gateway to other networks.
+
+1.4. Operation
+
+ The internet protocol implements two basic functions: addressing and
+ fragmentation.
+
+ The internet modules use the addresses carried in the internet header
+ to transmit internet datagrams toward their destinations. The
+ selection of a path for transmission is called routing.
+
+ The internet modules use fields in the internet header to fragment and
+ reassemble internet datagrams when necessary for transmission through
+ "small packet" networks.
+
+ The model of operation is that an internet module resides in each host
+ engaged in internet communication and in each gateway that
+ interconnects networks. These modules share common rules for
+ interpreting address fields and for fragmenting and assembling
+ internet datagrams. In addition, these modules (especially in
+ gateways) have procedures for making routing decisions and other
+ functions.
+
+ The internet protocol treats each internet datagram as an independent
+ entity unrelated to any other internet datagram. There are no
+ connections or logical circuits (virtual or otherwise).
+
+ The internet protocol uses four key mechanisms in providing its
+ service: Type of Service, Time to Live, Options, and Header Checksum.
+
+ The Type of Service is used to indicate the quality of the service
+ desired. The type of service is an abstract or generalized set of
+ parameters which characterize the service choices provided in the
+ networks that make up the internet. This type of service indication
+ is to be used by gateways to select the actual transmission parameters
+ for a particular network, the network to be used for the next hop, or
+ the next gateway when routing an internet datagram.
+
+ The Time to Live is an indication of an upper bound on the lifetime of
+ an internet datagram. It is set by the sender of the datagram and
+ reduced at the points along the route where it is processed. If the
+ time to live reaches zero before the internet datagram reaches its
+ destination, the internet datagram is destroyed. The time to live can
+ be thought of as a self destruct time limit.
+
+
+[Page 2]
+
+
+September 1981
+ Internet Protocol
+ Introduction
+
+
+
+ The Options provide for control functions needed or useful in some
+ situations but unnecessary for the most common communications. The
+ options include provisions for timestamps, security, and special
+ routing.
+
+ The Header Checksum provides a verification that the information used
+ in processing internet datagram has been transmitted correctly. The
+ data may contain errors. If the header checksum fails, the internet
+ datagram is discarded at once by the entity which detects the error.
+
+ The internet protocol does not provide a reliable communication
+ facility. There are no acknowledgments either end-to-end or
+ hop-by-hop. There is no error control for data, only a header
+ checksum. There are no retransmissions. There is no flow control.
+
+ Errors detected may be reported via the Internet Control Message
+ Protocol (ICMP) [3] which is implemented in the internet protocol
+ module.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [Page 3]
+
+
+ September 1981
+Internet Protocol
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 4]
+
+
+September 1981
+ Internet Protocol
+
+
+
+ 2. OVERVIEW
+
+2.1. Relation to Other Protocols
+
+ The following diagram illustrates the place of the internet protocol
+ in the protocol hierarchy:
+
+
+ +------+ +-----+ +-----+ +-----+
+ |Telnet| | FTP | | TFTP| ... | ... |
+ +------+ +-----+ +-----+ +-----+
+ | | | |
+ +-----+ +-----+ +-----+
+ | TCP | | UDP | ... | ... |
+ +-----+ +-----+ +-----+
+ | | |
+ +--------------------------+----+
+ | Internet Protocol & ICMP |
+ +--------------------------+----+
+ |
+ +---------------------------+
+ | Local Network Protocol |
+ +---------------------------+
+
+ Protocol Relationships
+
+ Figure 1.
+
+ Internet protocol interfaces on one side to the higher level
+ host-to-host protocols and on the other side to the local network
+ protocol. In this context a "local network" may be a small network in
+ a building or a large network such as the ARPANET.
+
+2.2. Model of Operation
+
+ The model of operation for transmitting a datagram from one
+ application program to another is illustrated by the following
+ scenario:
+
+ We suppose that this transmission will involve one intermediate
+ gateway.
+
+ The sending application program prepares its data and calls on its
+ local internet module to send that data as a datagram and passes the
+ destination address and other parameters as arguments of the call.
+
+ The internet module prepares a datagram header and attaches the data
+ to it. The internet module determines a local network address for
+ this internet address, in this case it is the address of a gateway.
+
+
+ [Page 5]
+
+
+ September 1981
+Internet Protocol
+Overview
+
+
+
+ It sends this datagram and the local network address to the local
+ network interface.
+
+ The local network interface creates a local network header, and
+ attaches the datagram to it, then sends the result via the local
+ network.
+
+ The datagram arrives at a gateway host wrapped in the local network
+ header, the local network interface strips off this header, and
+ turns the datagram over to the internet module. The internet module
+ determines from the internet address that the datagram is to be
+ forwarded to another host in a second network. The internet module
+ determines a local net address for the destination host. It calls
+ on the local network interface for that network to send the
+ datagram.
+
+ This local network interface creates a local network header and
+ attaches the datagram sending the result to the destination host.
+
+ At this destination host the datagram is stripped of the local net
+ header by the local network interface and handed to the internet
+ module.
+
+ The internet module determines that the datagram is for an
+ application program in this host. It passes the data to the
+ application program in response to a system call, passing the source
+ address and other parameters as results of the call.
+
+
+ Application Application
+ Program Program
+ \ /
+ Internet Module Internet Module Internet Module
+ \ / \ /
+ LNI-1 LNI-1 LNI-2 LNI-2
+ \ / \ /
+ Local Network 1 Local Network 2
+
+
+
+ Transmission Path
+
+ Figure 2
+
+
+
+
+
+
+
+[Page 6]
+
+
+September 1981
+ Internet Protocol
+ Overview
+
+
+
+2.3. Function Description
+
+ The function or purpose of Internet Protocol is to move datagrams
+ through an interconnected set of networks. This is done by passing
+ the datagrams from one internet module to another until the
+ destination is reached. The internet modules reside in hosts and
+ gateways in the internet system. The datagrams are routed from one
+ internet module to another through individual networks based on the
+ interpretation of an internet address. Thus, one important mechanism
+ of the internet protocol is the internet address.
+
+ In the routing of messages from one internet module to another,
+ datagrams may need to traverse a network whose maximum packet size is
+ smaller than the size of the datagram. To overcome this difficulty, a
+ fragmentation mechanism is provided in the internet protocol.
+
+ Addressing
+
+ A distinction is made between names, addresses, and routes [4]. A
+ name indicates what we seek. An address indicates where it is. A
+ route indicates how to get there. The internet protocol deals
+ primarily with addresses. It is the task of higher level (i.e.,
+ host-to-host or application) protocols to make the mapping from
+ names to addresses. The internet module maps internet addresses to
+ local net addresses. It is the task of lower level (i.e., local net
+ or gateways) procedures to make the mapping from local net addresses
+ to routes.
+
+ Addresses are fixed length of four octets (32 bits). An address
+ begins with a network number, followed by local address (called the
+ "rest" field). There are three formats or classes of internet
+ addresses: in class a, the high order bit is zero, the next 7 bits
+ are the network, and the last 24 bits are the local address; in
+ class b, the high order two bits are one-zero, the next 14 bits are
+ the network and the last 16 bits are the local address; in class c,
+ the high order three bits are one-one-zero, the next 21 bits are the
+ network and the last 8 bits are the local address.
+
+ Care must be taken in mapping internet addresses to local net
+ addresses; a single physical host must be able to act as if it were
+ several distinct hosts to the extent of using several distinct
+ internet addresses. Some hosts will also have several physical
+ interfaces (multi-homing).
+
+ That is, provision must be made for a host to have several physical
+ interfaces to the network with each having several logical internet
+ addresses.
+
+
+
+ [Page 7]
+
+
+ September 1981
+Internet Protocol
+Overview
+
+
+
+ Examples of address mappings may be found in "Address Mappings" [5].
+
+ Fragmentation
+
+ Fragmentation of an internet datagram is necessary when it
+ originates in a local net that allows a large packet size and must
+ traverse a local net that limits packets to a smaller size to reach
+ its destination.
+
+ An internet datagram can be marked "don't fragment." Any internet
+ datagram so marked is not to be internet fragmented under any
+ circumstances. If internet datagram marked don't fragment cannot be
+ delivered to its destination without fragmenting it, it is to be
+ discarded instead.
+
+ Fragmentation, transmission and reassembly across a local network
+ which is invisible to the internet protocol module is called
+ intranet fragmentation and may be used [6].
+
+ The internet fragmentation and reassembly procedure needs to be able
+ to break a datagram into an almost arbitrary number of pieces that
+ can be later reassembled. The receiver of the fragments uses the
+ identification field to ensure that fragments of different datagrams
+ are not mixed. The fragment offset field tells the receiver the
+ position of a fragment in the original datagram. The fragment
+ offset and length determine the portion of the original datagram
+ covered by this fragment. The more-fragments flag indicates (by
+ being reset) the last fragment. These fields provide sufficient
+ information to reassemble datagrams.
+
+ The identification field is used to distinguish the fragments of one
+ datagram from those of another. The originating protocol module of
+ an internet datagram sets the identification field to a value that
+ must be unique for that source-destination pair and protocol for the
+ time the datagram will be active in the internet system. The
+ originating protocol module of a complete datagram sets the
+ more-fragments flag to zero and the fragment offset to zero.
+
+ To fragment a long internet datagram, an internet protocol module
+ (for example, in a gateway), creates two new internet datagrams and
+ copies the contents of the internet header fields from the long
+ datagram into both new internet headers. The data of the long
+ datagram is divided into two portions on a 8 octet (64 bit) boundary
+ (the second portion might not be an integral multiple of 8 octets,
+ but the first must be). Call the number of 8 octet blocks in the
+ first portion NFB (for Number of Fragment Blocks). The first
+ portion of the data is placed in the first new internet datagram,
+ and the total length field is set to the length of the first
+
+
+[Page 8]
+
+
+September 1981
+ Internet Protocol
+ Overview
+
+
+
+ datagram. The more-fragments flag is set to one. The second
+ portion of the data is placed in the second new internet datagram,
+ and the total length field is set to the length of the second
+ datagram. The more-fragments flag carries the same value as the
+ long datagram. The fragment offset field of the second new internet
+ datagram is set to the value of that field in the long datagram plus
+ NFB.
+
+ This procedure can be generalized for an n-way split, rather than
+ the two-way split described.
+
+ To assemble the fragments of an internet datagram, an internet
+ protocol module (for example at a destination host) combines
+ internet datagrams that all have the same value for the four fields:
+ identification, source, destination, and protocol. The combination
+ is done by placing the data portion of each fragment in the relative
+ position indicated by the fragment offset in that fragment's
+ internet header. The first fragment will have the fragment offset
+ zero, and the last fragment will have the more-fragments flag reset
+ to zero.
+
+2.4. Gateways
+
+ Gateways implement internet protocol to forward datagrams between
+ networks. Gateways also implement the Gateway to Gateway Protocol
+ (GGP) [7] to coordinate routing and other internet control
+ information.
+
+ In a gateway the higher level protocols need not be implemented and
+ the GGP functions are added to the IP module.
+
+
+ +-------------------------------+
+ | Internet Protocol & ICMP & GGP|
+ +-------------------------------+
+ | |
+ +---------------+ +---------------+
+ | Local Net | | Local Net |
+ +---------------+ +---------------+
+
+ Gateway Protocols
+
+ Figure 3.
+
+
+
+
+
+
+
+ [Page 9]
+
+
+ September 1981
+Internet Protocol
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 10]
+
+
+September 1981
+ Internet Protocol
+
+
+
+ 3. SPECIFICATION
+
+3.1. Internet Header Format
+
+ A summary of the contents of the internet header 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |Version| IHL |Type of Service| Total Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Identification |Flags| Fragment Offset |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Time to Live | Protocol | Header Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Source Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Destination Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Options | Padding |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Example Internet Datagram Header
+
+ Figure 4.
+
+ Note that each tick mark represents one bit position.
+
+ Version: 4 bits
+
+ The Version field indicates the format of the internet header. This
+ document describes version 4.
+
+ IHL: 4 bits
+
+ Internet Header Length is the length of the internet header in 32
+ bit words, and thus points to the beginning of the data. Note that
+ the minimum value for a correct header is 5.
+
+
+
+
+
+
+
+
+
+
+
+
+ [Page 11]
+
+
+ September 1981
+Internet Protocol
+Specification
+
+
+
+ Type of Service: 8 bits
+
+ The Type of Service provides an indication of the abstract
+ parameters of the quality of service desired. These parameters are
+ to be used to guide the selection of the actual service parameters
+ when transmitting a datagram through a particular network. Several
+ networks offer service precedence, which somehow treats high
+ precedence traffic as more important than other traffic (generally
+ by accepting only traffic above a certain precedence at time of high
+ load). The major choice is a three way tradeoff between low-delay,
+ high-reliability, and high-throughput.
+
+ Bits 0-2: Precedence.
+ Bit 3: 0 = Normal Delay, 1 = Low Delay.
+ Bits 4: 0 = Normal Throughput, 1 = High Throughput.
+ Bits 5: 0 = Normal Relibility, 1 = High Relibility.
+ Bit 6-7: Reserved for Future Use.
+
+ 0 1 2 3 4 5 6 7
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | | | | | | |
+ | PRECEDENCE | D | T | R | 0 | 0 |
+ | | | | | | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+
+ Precedence
+
+ 111 - Network Control
+ 110 - Internetwork Control
+ 101 - CRITIC/ECP
+ 100 - Flash Override
+ 011 - Flash
+ 010 - Immediate
+ 001 - Priority
+ 000 - Routine
+
+ The use of the Delay, Throughput, and Reliability indications may
+ increase the cost (in some sense) of the service. In many networks
+ better performance for one of these parameters is coupled with worse
+ performance on another. Except for very unusual cases at most two
+ of these three indications should be set.
+
+ The type of service is used to specify the treatment of the datagram
+ during its transmission through the internet system. Example
+ mappings of the internet type of service to the actual service
+ provided on networks such as AUTODIN II, ARPANET, SATNET, and PRNET
+ is given in "Service Mappings" [8].
+
+
+
+[Page 12]
+
+
+September 1981
+ Internet Protocol
+ Specification
+
+
+
+ The Network Control precedence designation is intended to be used
+ within a network only. The actual use and control of that
+ designation is up to each network. The Internetwork Control
+ designation is intended for use by gateway control originators only.
+ If the actual use of these precedence designations is of concern to
+ a particular network, it is the responsibility of that network to
+ control the access to, and use of, those precedence designations.
+
+ Total Length: 16 bits
+
+ Total Length is the length of the datagram, measured in octets,
+ including internet header and data. This field allows the length of
+ a datagram to be up to 65,535 octets. Such long datagrams are
+ impractical for most hosts and networks. All hosts must be prepared
+ to accept datagrams of up to 576 octets (whether they arrive whole
+ or in fragments). It is recommended that hosts only send datagrams
+ larger than 576 octets if they have assurance that the destination
+ is prepared to accept the larger datagrams.
+
+ The number 576 is selected to allow a reasonable sized data block to
+ be transmitted in addition to the required header information. For
+ example, this size allows a data block of 512 octets plus 64 header
+ octets to fit in a datagram. The maximal internet header is 60
+ octets, and a typical internet header is 20 octets, allowing a
+ margin for headers of higher level protocols.
+
+ Identification: 16 bits
+
+ An identifying value assigned by the sender to aid in assembling the
+ fragments of a datagram.
+
+ Flags: 3 bits
+
+ Various Control Flags.
+
+ Bit 0: reserved, must be zero
+ Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment.
+ Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments.
+
+ 0 1 2
+ +---+---+---+
+ | | D | M |
+ | 0 | F | F |
+ +---+---+---+
+
+ Fragment Offset: 13 bits
+
+ This field indicates where in the datagram this fragment belongs.
+
+
+ [Page 13]
+
+
+ September 1981
+Internet Protocol
+Specification
+
+
+
+ The fragment offset is measured in units of 8 octets (64 bits). The
+ first fragment has offset zero.
+
+ Time to Live: 8 bits
+
+ This field indicates the maximum time the datagram is allowed to
+ remain in the internet system. If this field contains the value
+ zero, then the datagram must be destroyed. This field is modified
+ in internet header processing. The time is measured in units of
+ seconds, but since every module that processes a datagram must
+ decrease the TTL by at least one even if it process the datagram in
+ less than a second, the TTL must be thought of only as an upper
+ bound on the time a datagram may exist. The intention is to cause
+ undeliverable datagrams to be discarded, and to bound the maximum
+ datagram lifetime.
+
+ Protocol: 8 bits
+
+ This field indicates the next level protocol used in the data
+ portion of the internet datagram. The values for various protocols
+ are specified in "Assigned Numbers" [9].
+
+ Header Checksum: 16 bits
+
+ A checksum on the header only. Since some header fields change
+ (e.g., time to live), this is recomputed and verified at each point
+ that the internet header is processed.
+
+ The checksum algorithm is:
+
+ The checksum field is the 16 bit one's complement of the one's
+ complement sum of all 16 bit words in the header. For purposes of
+ computing the checksum, the value of the checksum field is zero.
+
+ This is a simple to compute checksum and experimental evidence
+ indicates it is adequate, but it is provisional and may be replaced
+ by a CRC procedure, depending on further experience.
+
+ Source Address: 32 bits
+
+ The source address. See section 3.2.
+
+ Destination Address: 32 bits
+
+ The destination address. See section 3.2.
+
+
+
+
+
+[Page 14]
+
+
+September 1981
+ Internet Protocol
+ Specification
+
+
+
+ Options: variable
+
+ The options may appear or not in datagrams. They must be
+ implemented by all IP modules (host and gateways). What is optional
+ is their transmission in any particular datagram, not their
+ implementation.
+
+ In some environments the security option may be required in all
+ datagrams.
+
+ The option field is variable in length. There may be zero or more
+ options. There are two cases for the format of an option:
+
+ Case 1: A single octet of option-type.
+
+ Case 2: An option-type octet, an option-length octet, and the
+ actual option-data octets.
+
+ The option-length octet counts the option-type octet and the
+ option-length octet as well as the option-data octets.
+
+ The option-type octet is viewed as having 3 fields:
+
+ 1 bit copied flag,
+ 2 bits option class,
+ 5 bits option number.
+
+ The copied flag indicates that this option is copied into all
+ fragments on fragmentation.
+
+ 0 = not copied
+ 1 = copied
+
+ The option classes are:
+
+ 0 = control
+ 1 = reserved for future use
+ 2 = debugging and measurement
+ 3 = reserved for future use
+
+
+
+
+
+
+
+
+
+
+
+ [Page 15]
+
+
+ September 1981
+Internet Protocol
+Specification
+
+
+
+ The following internet options are defined:
+
+ CLASS NUMBER LENGTH DESCRIPTION
+ ----- ------ ------ -----------
+ 0 0 - End of Option list. This option occupies only
+ 1 octet; it has no length octet.
+ 0 1 - No Operation. This option occupies only 1
+ octet; it has no length octet.
+ 0 2 11 Security. Used to carry Security,
+ Compartmentation, User Group (TCC), and
+ Handling Restriction Codes compatible with DOD
+ requirements.
+ 0 3 var. Loose Source Routing. Used to route the
+ internet datagram based on information
+ supplied by the source.
+ 0 9 var. Strict Source Routing. Used to route the
+ internet datagram based on information
+ supplied by the source.
+ 0 7 var. Record Route. Used to trace the route an
+ internet datagram takes.
+ 0 8 4 Stream ID. Used to carry the stream
+ identifier.
+ 2 4 var. Internet Timestamp.
+
+
+
+ Specific Option Definitions
+
+ End of Option List
+
+ +--------+
+ |00000000|
+ +--------+
+ Type=0
+
+ This option indicates the end of the option list. This might
+ not coincide with the end of the internet header according to
+ the internet header length. This is used at the end of all
+ options, not the end of each option, and need only be used if
+ the end of the options would not otherwise coincide with the end
+ of the internet header.
+
+ May be copied, introduced, or deleted on fragmentation, or for
+ any other reason.
+
+
+
+
+
+
+[Page 16]
+
+
+September 1981
+ Internet Protocol
+ Specification
+
+
+
+ No Operation
+
+ +--------+
+ |00000001|
+ +--------+
+ Type=1
+
+ This option may be used between options, for example, to align
+ the beginning of a subsequent option on a 32 bit boundary.
+
+ May be copied, introduced, or deleted on fragmentation, or for
+ any other reason.
+
+ Security
+
+ This option provides a way for hosts to send security,
+ compartmentation, handling restrictions, and TCC (closed user
+ group) parameters. The format for this option is as follows:
+
+ +--------+--------+---//---+---//---+---//---+---//---+
+ |10000010|00001011|SSS SSS|CCC CCC|HHH HHH| TCC |
+ +--------+--------+---//---+---//---+---//---+---//---+
+ Type=130 Length=11
+
+ Security (S field): 16 bits
+
+ Specifies one of 16 levels of security (eight of which are
+ reserved for future use).
+
+ 00000000 00000000 - Unclassified
+ 11110001 00110101 - Confidential
+ 01111000 10011010 - EFTO
+ 10111100 01001101 - MMMM
+ 01011110 00100110 - PROG
+ 10101111 00010011 - Restricted
+ 11010111 10001000 - Secret
+ 01101011 11000101 - Top Secret
+ 00110101 11100010 - (Reserved for future use)
+ 10011010 11110001 - (Reserved for future use)
+ 01001101 01111000 - (Reserved for future use)
+ 00100100 10111101 - (Reserved for future use)
+ 00010011 01011110 - (Reserved for future use)
+ 10001001 10101111 - (Reserved for future use)
+ 11000100 11010110 - (Reserved for future use)
+ 11100010 01101011 - (Reserved for future use)
+
+
+
+
+
+ [Page 17]
+
+
+ September 1981
+Internet Protocol
+Specification
+
+
+
+ Compartments (C field): 16 bits
+
+ An all zero value is used when the information transmitted is
+ not compartmented. Other values for the compartments field
+ may be obtained from the Defense Intelligence Agency.
+
+ Handling Restrictions (H field): 16 bits
+
+ The values for the control and release markings are
+ alphanumeric digraphs and are defined in the Defense
+ Intelligence Agency Manual DIAM 65-19, "Standard Security
+ Markings".
+
+ Transmission Control Code (TCC field): 24 bits
+
+ Provides a means to segregate traffic and define controlled
+ communities of interest among subscribers. The TCC values are
+ trigraphs, and are available from HQ DCA Code 530.
+
+ Must be copied on fragmentation. This option appears at most
+ once in a datagram.
+
+ Loose Source and Record Route
+
+ +--------+--------+--------+---------//--------+
+ |10000011| length | pointer| route data |
+ +--------+--------+--------+---------//--------+
+ Type=131
+
+ The loose source and record route (LSRR) option provides a means
+ for the source of an internet datagram to supply routing
+ information to be used by the gateways in forwarding the
+ datagram to the destination, and to record the route
+ information.
+
+ The option begins with the option type code. The second octet
+ is the option length which includes the option type code and the
+ length octet, the pointer octet, and length-3 octets of route
+ data. The third octet is the pointer into the route data
+ indicating the octet which begins the next source address to be
+ processed. The pointer is relative to this option, and the
+ smallest legal value for the pointer is 4.
+
+ A route data is composed of a series of internet addresses.
+ Each internet address is 32 bits or 4 octets. If the pointer is
+ greater than the length, the source route is empty (and the
+ recorded route full) and the routing is to be based on the
+ destination address field.
+
+
+[Page 18]
+
+
+September 1981
+ Internet Protocol
+ Specification
+
+
+
+ If the address in destination address field has been reached and
+ the pointer is not greater than the length, the next address in
+ the source route replaces the address in the destination address
+ field, and the recorded route address replaces the source
+ address just used, and pointer is increased by four.
+
+ The recorded route address is the internet module's own internet
+ address as known in the environment into which this datagram is
+ being forwarded.
+
+ This procedure of replacing the source route with the recorded
+ route (though it is in the reverse of the order it must be in to
+ be used as a source route) means the option (and the IP header
+ as a whole) remains a constant length as the datagram progresses
+ through the internet.
+
+ This option is a loose source route because the gateway or host
+ IP is allowed to use any route of any number of other
+ intermediate gateways to reach the next address in the route.
+
+ Must be copied on fragmentation. Appears at most once in a
+ datagram.
+
+ Strict Source and Record Route
+
+ +--------+--------+--------+---------//--------+
+ |10001001| length | pointer| route data |
+ +--------+--------+--------+---------//--------+
+ Type=137
+
+ The strict source and record route (SSRR) option provides a
+ means for the source of an internet datagram to supply routing
+ information to be used by the gateways in forwarding the
+ datagram to the destination, and to record the route
+ information.
+
+ The option begins with the option type code. The second octet
+ is the option length which includes the option type code and the
+ length octet, the pointer octet, and length-3 octets of route
+ data. The third octet is the pointer into the route data
+ indicating the octet which begins the next source address to be
+ processed. The pointer is relative to this option, and the
+ smallest legal value for the pointer is 4.
+
+ A route data is composed of a series of internet addresses.
+ Each internet address is 32 bits or 4 octets. If the pointer is
+ greater than the length, the source route is empty (and the
+
+
+
+ [Page 19]
+
+
+ September 1981
+Internet Protocol
+Specification
+
+
+
+ recorded route full) and the routing is to be based on the
+ destination address field.
+
+ If the address in destination address field has been reached and
+ the pointer is not greater than the length, the next address in
+ the source route replaces the address in the destination address
+ field, and the recorded route address replaces the source
+ address just used, and pointer is increased by four.
+
+ The recorded route address is the internet module's own internet
+ address as known in the environment into which this datagram is
+ being forwarded.
+
+ This procedure of replacing the source route with the recorded
+ route (though it is in the reverse of the order it must be in to
+ be used as a source route) means the option (and the IP header
+ as a whole) remains a constant length as the datagram progresses
+ through the internet.
+
+ This option is a strict source route because the gateway or host
+ IP must send the datagram directly to the next address in the
+ source route through only the directly connected network
+ indicated in the next address to reach the next gateway or host
+ specified in the route.
+
+ Must be copied on fragmentation. Appears at most once in a
+ datagram.
+
+ Record Route
+
+ +--------+--------+--------+---------//--------+
+ |00000111| length | pointer| route data |
+ +--------+--------+--------+---------//--------+
+ Type=7
+
+ The record route option provides a means to record the route of
+ an internet datagram.
+
+ The option begins with the option type code. The second octet
+ is the option length which includes the option type code and the
+ length octet, the pointer octet, and length-3 octets of route
+ data. The third octet is the pointer into the route data
+ indicating the octet which begins the next area to store a route
+ address. The pointer is relative to this option, and the
+ smallest legal value for the pointer is 4.
+
+ A recorded route is composed of a series of internet addresses.
+ Each internet address is 32 bits or 4 octets. If the pointer is
+
+
+[Page 20]
+
+
+September 1981
+ Internet Protocol
+ Specification
+
+
+
+ greater than the length, the recorded route data area is full.
+ The originating host must compose this option with a large
+ enough route data area to hold all the address expected. The
+ size of the option does not change due to adding addresses. The
+ intitial contents of the route data area must be zero.
+
+ When an internet module routes a datagram it checks to see if
+ the record route option is present. If it is, it inserts its
+ own internet address as known in the environment into which this
+ datagram is being forwarded into the recorded route begining at
+ the octet indicated by the pointer, and increments the pointer
+ by four.
+
+ If the route data area is already full (the pointer exceeds the
+ length) the datagram is forwarded without inserting the address
+ into the recorded route. If there is some room but not enough
+ room for a full address to be inserted, the original datagram is
+ considered to be in error and is discarded. In either case an
+ ICMP parameter problem message may be sent to the source
+ host [3].
+
+ Not copied on fragmentation, goes in first fragment only.
+ Appears at most once in a datagram.
+
+ Stream Identifier
+
+ +--------+--------+--------+--------+
+ |10001000|00000010| Stream ID |
+ +--------+--------+--------+--------+
+ Type=136 Length=4
+
+ This option provides a way for the 16-bit SATNET stream
+ identifier to be carried through networks that do not support
+ the stream concept.
+
+ Must be copied on fragmentation. Appears at most once in a
+ datagram.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [Page 21]
+
+
+ September 1981
+Internet Protocol
+Specification
+
+
+
+ Internet Timestamp
+
+ +--------+--------+--------+--------+
+ |01000100| length | pointer|oflw|flg|
+ +--------+--------+--------+--------+
+ | internet address |
+ +--------+--------+--------+--------+
+ | timestamp |
+ +--------+--------+--------+--------+
+ | . |
+ .
+ .
+ Type = 68
+
+ The Option Length is the number of octets in the option counting
+ the type, length, pointer, and overflow/flag octets (maximum
+ length 40).
+
+ The Pointer is the number of octets from the beginning of this
+ option to the end of timestamps plus one (i.e., it points to the
+ octet beginning the space for next timestamp). The smallest
+ legal value is 5. The timestamp area is full when the pointer
+ is greater than the length.
+
+ The Overflow (oflw) [4 bits] is the number of IP modules that
+ cannot register timestamps due to lack of space.
+
+ The Flag (flg) [4 bits] values are
+
+ 0 -- time stamps only, stored in consecutive 32-bit words,
+
+ 1 -- each timestamp is preceded with internet address of the
+ registering entity,
+
+ 3 -- the internet address fields are prespecified. An IP
+ module only registers its timestamp if it matches its own
+ address with the next specified internet address.
+
+ The Timestamp is a right-justified, 32-bit timestamp in
+ milliseconds since midnight UT. If the time is not available in
+ milliseconds or cannot be provided with respect to midnight UT
+ then any time may be inserted as a timestamp provided the high
+ order bit of the timestamp field is set to one to indicate the
+ use of a non-standard value.
+
+ The originating host must compose this option with a large
+ enough timestamp data area to hold all the timestamp information
+ expected. The size of the option does not change due to adding
+
+
+[Page 22]
+
+
+September 1981
+ Internet Protocol
+ Specification
+
+
+
+ timestamps. The intitial contents of the timestamp data area
+ must be zero or internet address/zero pairs.
+
+ If the timestamp data area is already full (the pointer exceeds
+ the length) the datagram is forwarded without inserting the
+ timestamp, but the overflow count is incremented by one.
+
+ If there is some room but not enough room for a full timestamp
+ to be inserted, or the overflow count itself overflows, the
+ original datagram is considered to be in error and is discarded.
+ In either case an ICMP parameter problem message may be sent to
+ the source host [3].
+
+ The timestamp option is not copied upon fragmentation. It is
+ carried in the first fragment. Appears at most once in a
+ datagram.
+
+ Padding: variable
+
+ The internet header padding is used to ensure that the internet
+ header ends on a 32 bit boundary. The padding is zero.
+
+3.2. Discussion
+
+ The implementation of a protocol must be robust. Each implementation
+ must expect to interoperate with others created by different
+ individuals. While the goal of this specification is to be explicit
+ about the protocol there is the possibility of differing
+ interpretations. In general, an implementation must be conservative
+ in its sending behavior, and liberal in its receiving behavior. That
+ is, it must be careful to send well-formed datagrams, but must accept
+ any datagram that it can interpret (e.g., not object to technical
+ errors where the meaning is still clear).
+
+ The basic internet service is datagram oriented and provides for the
+ fragmentation of datagrams at gateways, with reassembly taking place
+ at the destination internet protocol module in the destination host.
+ Of course, fragmentation and reassembly of datagrams within a network
+ or by private agreement between the gateways of a network is also
+ allowed since this is transparent to the internet protocols and the
+ higher-level protocols. This transparent type of fragmentation and
+ reassembly is termed "network-dependent" (or intranet) fragmentation
+ and is not discussed further here.
+
+ Internet addresses distinguish sources and destinations to the host
+ level and provide a protocol field as well. It is assumed that each
+ protocol will provide for whatever multiplexing is necessary within a
+ host.
+
+
+ [Page 23]
+
+
+ September 1981
+Internet Protocol
+Specification
+
+
+
+ Addressing
+
+ To provide for flexibility in assigning address to networks and
+ allow for the large number of small to intermediate sized networks
+ the interpretation of the address field is coded to specify a small
+ number of networks with a large number of host, a moderate number of
+ networks with a moderate number of hosts, and a large number of
+ networks with a small number of hosts. In addition there is an
+ escape code for extended addressing mode.
+
+ Address Formats:
+
+ High Order Bits Format Class
+ --------------- ------------------------------- -----
+ 0 7 bits of net, 24 bits of host a
+ 10 14 bits of net, 16 bits of host b
+ 110 21 bits of net, 8 bits of host c
+ 111 escape to extended addressing mode
+
+ A value of zero in the network field means this network. This is
+ only used in certain ICMP messages. The extended addressing mode
+ is undefined. Both of these features are reserved for future use.
+
+ The actual values assigned for network addresses is given in
+ "Assigned Numbers" [9].
+
+ The local address, assigned by the local network, must allow for a
+ single physical host to act as several distinct internet hosts.
+ That is, there must be a mapping between internet host addresses and
+ network/host interfaces that allows several internet addresses to
+ correspond to one interface. It must also be allowed for a host to
+ have several physical interfaces and to treat the datagrams from
+ several of them as if they were all addressed to a single host.
+
+ Address mappings between internet addresses and addresses for
+ ARPANET, SATNET, PRNET, and other networks are described in "Address
+ Mappings" [5].
+
+ Fragmentation and Reassembly.
+
+ The internet identification field (ID) is used together with the
+ source and destination address, and the protocol fields, to identify
+ datagram fragments for reassembly.
+
+ The More Fragments flag bit (MF) is set if the datagram is not the
+ last fragment. The Fragment Offset field identifies the fragment
+ location, relative to the beginning of the original unfragmented
+ datagram. Fragments are counted in units of 8 octets. The
+
+
+[Page 24]
+
+
+September 1981
+ Internet Protocol
+ Specification
+
+
+
+ fragmentation strategy is designed so than an unfragmented datagram
+ has all zero fragmentation information (MF = 0, fragment offset =
+ 0). If an internet datagram is fragmented, its data portion must be
+ broken on 8 octet boundaries.
+
+ This format allows 2**13 = 8192 fragments of 8 octets each for a
+ total of 65,536 octets. Note that this is consistent with the the
+ datagram total length field (of course, the header is counted in the
+ total length and not in the fragments).
+
+ When fragmentation occurs, some options are copied, but others
+ remain with the first fragment only.
+
+ Every internet module must be able to forward a datagram of 68
+ octets without further fragmentation. This is because an internet
+ header may be up to 60 octets, and the minimum fragment is 8 octets.
+
+ Every internet destination must be able to receive a datagram of 576
+ octets either in one piece or in fragments to be reassembled.
+
+ The fields which may be affected by fragmentation include:
+
+ (1) options field
+ (2) more fragments flag
+ (3) fragment offset
+ (4) internet header length field
+ (5) total length field
+ (6) header checksum
+
+ If the Don't Fragment flag (DF) bit is set, then internet
+ fragmentation of this datagram is NOT permitted, although it may be
+ discarded. This can be used to prohibit fragmentation in cases
+ where the receiving host does not have sufficient resources to
+ reassemble internet fragments.
+
+ One example of use of the Don't Fragment feature is to down line
+ load a small host. A small host could have a boot strap program
+ that accepts a datagram stores it in memory and then executes it.
+
+ The fragmentation and reassembly procedures are most easily
+ described by examples. The following procedures are example
+ implementations.
+
+ General notation in the following pseudo programs: "=<" means "less
+ than or equal", "#" means "not equal", "=" means "equal", "<-" means
+ "is set to". Also, "x to y" includes x and excludes y; for example,
+ "4 to 7" would include 4, 5, and 6 (but not 7).
+
+
+
+ [Page 25]
+
+
+ September 1981
+Internet Protocol
+Specification
+
+
+
+ An Example Fragmentation Procedure
+
+ The maximum sized datagram that can be transmitted through the
+ next network is called the maximum transmission unit (MTU).
+
+ If the total length is less than or equal the maximum transmission
+ unit then submit this datagram to the next step in datagram
+ processing; otherwise cut the datagram into two fragments, the
+ first fragment being the maximum size, and the second fragment
+ being the rest of the datagram. The first fragment is submitted
+ to the next step in datagram processing, while the second fragment
+ is submitted to this procedure in case it is still too large.
+
+ Notation:
+
+ FO - Fragment Offset
+ IHL - Internet Header Length
+ DF - Don't Fragment flag
+ MF - More Fragments flag
+ TL - Total Length
+ OFO - Old Fragment Offset
+ OIHL - Old Internet Header Length
+ OMF - Old More Fragments flag
+ OTL - Old Total Length
+ NFB - Number of Fragment Blocks
+ MTU - Maximum Transmission Unit
+
+ Procedure:
+
+ IF TL =< MTU THEN Submit this datagram to the next step
+ in datagram processing ELSE IF DF = 1 THEN discard the
+ datagram ELSE
+ To produce the first fragment:
+ (1) Copy the original internet header;
+ (2) OIHL <- IHL; OTL <- TL; OFO <- FO; OMF <- MF;
+ (3) NFB <- (MTU-IHL*4)/8;
+ (4) Attach the first NFB*8 data octets;
+ (5) Correct the header:
+ MF <- 1; TL <- (IHL*4)+(NFB*8);
+ Recompute Checksum;
+ (6) Submit this fragment to the next step in
+ datagram processing;
+ To produce the second fragment:
+ (7) Selectively copy the internet header (some options
+ are not copied, see option definitions);
+ (8) Append the remaining data;
+ (9) Correct the header:
+ IHL <- (((OIHL*4)-(length of options not copied))+3)/4;
+
+
+[Page 26]
+
+
+September 1981
+ Internet Protocol
+ Specification
+
+
+
+ TL <- OTL - NFB*8 - (OIHL-IHL)*4);
+ FO <- OFO + NFB; MF <- OMF; Recompute Checksum;
+ (10) Submit this fragment to the fragmentation test; DONE.
+
+ In the above procedure each fragment (except the last) was made
+ the maximum allowable size. An alternative might produce less
+ than the maximum size datagrams. For example, one could implement
+ a fragmentation procedure that repeatly divided large datagrams in
+ half until the resulting fragments were less than the maximum
+ transmission unit size.
+
+ An Example Reassembly Procedure
+
+ For each datagram the buffer identifier is computed as the
+ concatenation of the source, destination, protocol, and
+ identification fields. If this is a whole datagram (that is both
+ the fragment offset and the more fragments fields are zero), then
+ any reassembly resources associated with this buffer identifier
+ are released and the datagram is forwarded to the next step in
+ datagram processing.
+
+ If no other fragment with this buffer identifier is on hand then
+ reassembly resources are allocated. The reassembly resources
+ consist of a data buffer, a header buffer, a fragment block bit
+ table, a total data length field, and a timer. The data from the
+ fragment is placed in the data buffer according to its fragment
+ offset and length, and bits are set in the fragment block bit
+ table corresponding to the fragment blocks received.
+
+ If this is the first fragment (that is the fragment offset is
+ zero) this header is placed in the header buffer. If this is the
+ last fragment ( that is the more fragments field is zero) the
+ total data length is computed. If this fragment completes the
+ datagram (tested by checking the bits set in the fragment block
+ table), then the datagram is sent to the next step in datagram
+ processing; otherwise the timer is set to the maximum of the
+ current timer value and the value of the time to live field from
+ this fragment; and the reassembly routine gives up control.
+
+ If the timer runs out, the all reassembly resources for this
+ buffer identifier are released. The initial setting of the timer
+ is a lower bound on the reassembly waiting time. This is because
+ the waiting time will be increased if the Time to Live in the
+ arriving fragment is greater than the current timer value but will
+ not be decreased if it is less. The maximum this timer value
+ could reach is the maximum time to live (approximately 4.25
+ minutes). The current recommendation for the initial timer
+ setting is 15 seconds. This may be changed as experience with
+
+
+ [Page 27]
+
+
+ September 1981
+Internet Protocol
+Specification
+
+
+
+ this protocol accumulates. Note that the choice of this parameter
+ value is related to the buffer capacity available and the data
+ rate of the transmission medium; that is, data rate times timer
+ value equals buffer size (e.g., 10Kb/s X 15s = 150Kb).
+
+ Notation:
+
+ FO - Fragment Offset
+ IHL - Internet Header Length
+ MF - More Fragments flag
+ TTL - Time To Live
+ NFB - Number of Fragment Blocks
+ TL - Total Length
+ TDL - Total Data Length
+ BUFID - Buffer Identifier
+ RCVBT - Fragment Received Bit Table
+ TLB - Timer Lower Bound
+
+ Procedure:
+
+ (1) BUFID <- source|destination|protocol|identification;
+ (2) IF FO = 0 AND MF = 0
+ (3) THEN IF buffer with BUFID is allocated
+ (4) THEN flush all reassembly for this BUFID;
+ (5) Submit datagram to next step; DONE.
+ (6) ELSE IF no buffer with BUFID is allocated
+ (7) THEN allocate reassembly resources
+ with BUFID;
+ TIMER <- TLB; TDL <- 0;
+ (8) put data from fragment into data buffer with
+ BUFID from octet FO*8 to
+ octet (TL-(IHL*4))+FO*8;
+ (9) set RCVBT bits from FO
+ to FO+((TL-(IHL*4)+7)/8);
+ (10) IF MF = 0 THEN TDL <- TL-(IHL*4)+(FO*8)
+ (11) IF FO = 0 THEN put header in header buffer
+ (12) IF TDL # 0
+ (13) AND all RCVBT bits from 0
+ to (TDL+7)/8 are set
+ (14) THEN TL <- TDL+(IHL*4)
+ (15) Submit datagram to next step;
+ (16) free all reassembly resources
+ for this BUFID; DONE.
+ (17) TIMER <- MAX(TIMER,TTL);
+ (18) give up until next fragment or timer expires;
+ (19) timer expires: flush all reassembly with this BUFID; DONE.
+
+ In the case that two or more fragments contain the same data
+
+
+[Page 28]
+
+
+September 1981
+ Internet Protocol
+ Specification
+
+
+
+ either identically or through a partial overlap, this procedure
+ will use the more recently arrived copy in the data buffer and
+ datagram delivered.
+
+ Identification
+
+ The choice of the Identifier for a datagram is based on the need to
+ provide a way to uniquely identify the fragments of a particular
+ datagram. The protocol module assembling fragments judges fragments
+ to belong to the same datagram if they have the same source,
+ destination, protocol, and Identifier. Thus, the sender must choose
+ the Identifier to be unique for this source, destination pair and
+ protocol for the time the datagram (or any fragment of it) could be
+ alive in the internet.
+
+ It seems then that a sending protocol module needs to keep a table
+ of Identifiers, one entry for each destination it has communicated
+ with in the last maximum packet lifetime for the internet.
+
+ However, since the Identifier field allows 65,536 different values,
+ some host may be able to simply use unique identifiers independent
+ of destination.
+
+ It is appropriate for some higher level protocols to choose the
+ identifier. For example, TCP protocol modules may retransmit an
+ identical TCP segment, and the probability for correct reception
+ would be enhanced if the retransmission carried the same identifier
+ as the original transmission since fragments of either datagram
+ could be used to construct a correct TCP segment.
+
+ Type of Service
+
+ The type of service (TOS) is for internet service quality selection.
+ The type of service is specified along the abstract parameters
+ precedence, delay, throughput, and reliability. These abstract
+ parameters are to be mapped into the actual service parameters of
+ the particular networks the datagram traverses.
+
+ Precedence. An independent measure of the importance of this
+ datagram.
+
+ Delay. Prompt delivery is important for datagrams with this
+ indication.
+
+ Throughput. High data rate is important for datagrams with this
+ indication.
+
+
+
+
+ [Page 29]
+
+
+ September 1981
+Internet Protocol
+Specification
+
+
+
+ Reliability. A higher level of effort to ensure delivery is
+ important for datagrams with this indication.
+
+ For example, the ARPANET has a priority bit, and a choice between
+ "standard" messages (type 0) and "uncontrolled" messages (type 3),
+ (the choice between single packet and multipacket messages can also
+ be considered a service parameter). The uncontrolled messages tend
+ to be less reliably delivered and suffer less delay. Suppose an
+ internet datagram is to be sent through the ARPANET. Let the
+ internet type of service be given as:
+
+ Precedence: 5
+ Delay: 0
+ Throughput: 1
+ Reliability: 1
+
+ In this example, the mapping of these parameters to those available
+ for the ARPANET would be to set the ARPANET priority bit on since
+ the Internet precedence is in the upper half of its range, to select
+ standard messages since the throughput and reliability requirements
+ are indicated and delay is not. More details are given on service
+ mappings in "Service Mappings" [8].
+
+ Time to Live
+
+ The time to live is set by the sender to the maximum time the
+ datagram is allowed to be in the internet system. If the datagram
+ is in the internet system longer than the time to live, then the
+ datagram must be destroyed.
+
+ This field must be decreased at each point that the internet header
+ is processed to reflect the time spent processing the datagram.
+ Even if no local information is available on the time actually
+ spent, the field must be decremented by 1. The time is measured in
+ units of seconds (i.e. the value 1 means one second). Thus, the
+ maximum time to live is 255 seconds or 4.25 minutes. Since every
+ module that processes a datagram must decrease the TTL by at least
+ one even if it process the datagram in less than a second, the TTL
+ must be thought of only as an upper bound on the time a datagram may
+ exist. The intention is to cause undeliverable datagrams to be
+ discarded, and to bound the maximum datagram lifetime.
+
+ Some higher level reliable connection protocols are based on
+ assumptions that old duplicate datagrams will not arrive after a
+ certain time elapses. The TTL is a way for such protocols to have
+ an assurance that their assumption is met.
+
+
+
+
+[Page 30]
+
+
+September 1981
+ Internet Protocol
+ Specification
+
+
+
+ Options
+
+ The options are optional in each datagram, but required in
+ implementations. That is, the presence or absence of an option is
+ the choice of the sender, but each internet module must be able to
+ parse every option. There can be several options present in the
+ option field.
+
+ The options might not end on a 32-bit boundary. The internet header
+ must be filled out with octets of zeros. The first of these would
+ be interpreted as the end-of-options option, and the remainder as
+ internet header padding.
+
+ Every internet module must be able to act on every option. The
+ Security Option is required if classified, restricted, or
+ compartmented traffic is to be passed.
+
+ Checksum
+
+ The internet header checksum is recomputed if the internet header is
+ changed. For example, a reduction of the time to live, additions or
+ changes to internet options, or due to fragmentation. This checksum
+ at the internet level is intended to protect the internet header
+ fields from transmission errors.
+
+ There are some applications where a few data bit errors are
+ acceptable while retransmission delays are not. If the internet
+ protocol enforced data correctness such applications could not be
+ supported.
+
+ Errors
+
+ Internet protocol errors may be reported via the ICMP messages [3].
+
+3.3. Interfaces
+
+ The functional description of user interfaces to the IP is, at best,
+ fictional, since every operating system will have different
+ facilities. Consequently, we must warn readers that different IP
+ implementations may have different user interfaces. However, all IPs
+ must provide a certain minimum set of services to guarantee that all
+ IP implementations can support the same protocol hierarchy. This
+ section specifies the functional interfaces required of all IP
+ implementations.
+
+ Internet protocol interfaces on one side to the local network and on
+ the other side to either a higher level protocol or an application
+ program. In the following, the higher level protocol or application
+
+
+ [Page 31]
+
+
+ September 1981
+Internet Protocol
+Specification
+
+
+
+ program (or even a gateway program) will be called the "user" since it
+ is using the internet module. Since internet protocol is a datagram
+ protocol, there is minimal memory or state maintained between datagram
+ transmissions, and each call on the internet protocol module by the
+ user supplies all information necessary for the IP to perform the
+ service requested.
+
+ An Example Upper Level Interface
+
+ The following two example calls satisfy the requirements for the user
+ to internet protocol module communication ("=>" means returns):
+
+ SEND (src, dst, prot, TOS, TTL, BufPTR, len, Id, DF, opt => result)
+
+ where:
+
+ src = source address
+ dst = destination address
+ prot = protocol
+ TOS = type of service
+ TTL = time to live
+ BufPTR = buffer pointer
+ len = length of buffer
+ Id = Identifier
+ DF = Don't Fragment
+ opt = option data
+ result = response
+ OK = datagram sent ok
+ Error = error in arguments or local network error
+
+ Note that the precedence is included in the TOS and the
+ security/compartment is passed as an option.
+
+ RECV (BufPTR, prot, => result, src, dst, TOS, len, opt)
+
+ where:
+
+ BufPTR = buffer pointer
+ prot = protocol
+ result = response
+ OK = datagram received ok
+ Error = error in arguments
+ len = length of buffer
+ src = source address
+ dst = destination address
+ TOS = type of service
+ opt = option data
+
+
+
+[Page 32]
+
+
+September 1981
+ Internet Protocol
+ Specification
+
+
+
+ When the user sends a datagram, it executes the SEND call supplying
+ all the arguments. The internet protocol module, on receiving this
+ call, checks the arguments and prepares and sends the message. If the
+ arguments are good and the datagram is accepted by the local network,
+ the call returns successfully. If either the arguments are bad, or
+ the datagram is not accepted by the local network, the call returns
+ unsuccessfully. On unsuccessful returns, a reasonable report must be
+ made as to the cause of the problem, but the details of such reports
+ are up to individual implementations.
+
+ When a datagram arrives at the internet protocol module from the local
+ network, either there is a pending RECV call from the user addressed
+ or there is not. In the first case, the pending call is satisfied by
+ passing the information from the datagram to the user. In the second
+ case, the user addressed is notified of a pending datagram. If the
+ user addressed does not exist, an ICMP error message is returned to
+ the sender, and the data is discarded.
+
+ The notification of a user may be via a pseudo interrupt or similar
+ mechanism, as appropriate in the particular operating system
+ environment of the implementation.
+
+ A user's RECV call may then either be immediately satisfied by a
+ pending datagram, or the call may be pending until a datagram arrives.
+
+ The source address is included in the send call in case the sending
+ host has several addresses (multiple physical connections or logical
+ addresses). The internet module must check to see that the source
+ address is one of the legal address for this host.
+
+ An implementation may also allow or require a call to the internet
+ module to indicate interest in or reserve exclusive use of a class of
+ datagrams (e.g., all those with a certain value in the protocol
+ field).
+
+ This section functionally characterizes a USER/IP interface. The
+ notation used is similar to most procedure of function calls in high
+ level languages, but this usage is not meant to rule out trap type
+ service calls (e.g., SVCs, UUOs, EMTs), or any other form of
+ interprocess communication.
+
+
+
+
+
+
+
+
+
+
+ [Page 33]
+
+
+ September 1981
+Internet Protocol
+
+
+
+APPENDIX A: Examples & Scenarios
+
+Example 1:
+
+ This is an example of the minimal data carrying internet datagram:
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |Ver= 4 |IHL= 5 |Type of Service| Total Length = 21 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Identification = 111 |Flg=0| Fragment Offset = 0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Time = 123 | Protocol = 1 | header checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | source address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | destination address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | data |
+ +-+-+-+-+-+-+-+-+
+
+ Example Internet Datagram
+
+ Figure 5.
+
+ Note that each tick mark represents one bit position.
+
+ This is a internet datagram in version 4 of internet protocol; the
+ internet header consists of five 32 bit words, and the total length of
+ the datagram is 21 octets. This datagram is a complete datagram (not
+ a fragment).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 34]
+
+
+September 1981
+ Internet Protocol
+
+
+
+Example 2:
+
+ In this example, we show first a moderate size internet datagram (452
+ data octets), then two internet fragments that might result from the
+ fragmentation of this datagram if the maximum sized transmission
+ allowed were 280 octets.
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |Ver= 4 |IHL= 5 |Type of Service| Total Length = 472 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Identification = 111 |Flg=0| Fragment Offset = 0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Time = 123 | Protocol = 6 | header checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | source address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | destination address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | data |
+ \ \
+ \ \
+ | data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Example Internet Datagram
+
+ Figure 6.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [Page 35]
+
+
+ September 1981
+Internet Protocol
+
+
+
+ Now the first fragment that results from splitting the datagram after
+ 256 data octets.
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |Ver= 4 |IHL= 5 |Type of Service| Total Length = 276 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Identification = 111 |Flg=1| Fragment Offset = 0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Time = 119 | Protocol = 6 | Header Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | source address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | destination address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | data |
+ \ \
+ \ \
+ | data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Example Internet Fragment
+
+ Figure 7.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 36]
+
+
+September 1981
+ Internet Protocol
+
+
+
+ And the second fragment.
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |Ver= 4 |IHL= 5 |Type of Service| Total Length = 216 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Identification = 111 |Flg=0| Fragment Offset = 32 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Time = 119 | Protocol = 6 | Header Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | source address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | destination address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | data |
+ \ \
+ \ \
+ | data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Example Internet Fragment
+
+ Figure 8.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [Page 37]
+
+
+ September 1981
+Internet Protocol
+
+
+
+Example 3:
+
+ Here, we show an example of a datagram containing options:
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |Ver= 4 |IHL= 8 |Type of Service| Total Length = 576 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Identification = 111 |Flg=0| Fragment Offset = 0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Time = 123 | Protocol = 6 | Header Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | source address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | destination address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Opt. Code = x | Opt. Len.= 3 | option value | Opt. Code = x |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Opt. Len. = 4 | option value | Opt. Code = 1 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Opt. Code = y | Opt. Len. = 3 | option value | Opt. Code = 0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | data |
+ \ \
+ \ \
+ | data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Example Internet Datagram
+
+ Figure 9.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 38]
+
+
+September 1981
+ Internet Protocol
+
+
+
+APPENDIX B: Data Transmission Order
+
+The order of transmission of the header and data described in this
+document is resolved to the octet level. Whenever a diagram shows a
+group of octets, the order of transmission of those octets is the normal
+order in which they are read in English. For example, in the following
+diagram the octets are transmitted in the order they are numbered.
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 1 | 2 | 3 | 4 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 5 | 6 | 7 | 8 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 9 | 10 | 11 | 12 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Transmission Order of Bytes
+
+ Figure 10.
+
+Whenever an octet represents a numeric quantity the left most bit in the
+diagram is the high order or most significant bit. That is, the bit
+labeled 0 is the most significant bit. For example, the following
+diagram represents the value 170 (decimal).
+
+
+ 0 1 2 3 4 5 6 7
+ +-+-+-+-+-+-+-+-+
+ |1 0 1 0 1 0 1 0|
+ +-+-+-+-+-+-+-+-+
+
+ Significance of Bits
+
+ Figure 11.
+
+Similarly, whenever a multi-octet field represents a numeric quantity
+the left most bit of the whole field is the most significant bit. When
+a multi-octet quantity is transmitted the most significant octet is
+transmitted first.
+
+
+
+
+
+
+
+
+
+ [Page 39]
+
+
+ September 1981
+Internet Protocol
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 40]
+
+
+September 1981
+ Internet Protocol
+
+
+
+ GLOSSARY
+
+
+
+1822
+ BBN Report 1822, "The Specification of the Interconnection of
+ a Host and an IMP". The specification of interface between a
+ host and the ARPANET.
+
+ARPANET leader
+ The control information on an ARPANET message at the host-IMP
+ interface.
+
+ARPANET message
+ The unit of transmission between a host and an IMP in the
+ ARPANET. The maximum size is about 1012 octets (8096 bits).
+
+ARPANET packet
+ A unit of transmission used internally in the ARPANET between
+ IMPs. The maximum size is about 126 octets (1008 bits).
+
+Destination
+ The destination address, an internet header field.
+
+DF
+ The Don't Fragment bit carried in the flags field.
+
+Flags
+ An internet header field carrying various control flags.
+
+Fragment Offset
+ This internet header field indicates where in the internet
+ datagram a fragment belongs.
+
+GGP
+ Gateway to Gateway Protocol, the protocol used primarily
+ between gateways to control routing and other gateway
+ functions.
+
+header
+ Control information at the beginning of a message, segment,
+ datagram, packet or block of data.
+
+ICMP
+ Internet Control Message Protocol, implemented in the internet
+ module, the ICMP is used from gateways to hosts and between
+ hosts to report errors and make routing suggestions.
+
+
+
+
+ [Page 41]
+
+
+ September 1981
+Internet Protocol
+Glossary
+
+
+
+Identification
+ An internet header field carrying the identifying value
+ assigned by the sender to aid in assembling the fragments of a
+ datagram.
+
+IHL
+ The internet header field Internet Header Length is the length
+ of the internet header measured in 32 bit words.
+
+IMP
+ The Interface Message Processor, the packet switch of the
+ ARPANET.
+
+Internet Address
+ A four octet (32 bit) source or destination address consisting
+ of a Network field and a Local Address field.
+
+internet datagram
+ The unit of data exchanged between a pair of internet modules
+ (includes the internet header).
+
+internet fragment
+ A portion of the data of an internet datagram with an internet
+ header.
+
+Local Address
+ The address of a host within a network. The actual mapping of
+ an internet local address on to the host addresses in a
+ network is quite general, allowing for many to one mappings.
+
+MF
+ The More-Fragments Flag carried in the internet header flags
+ field.
+
+module
+ An implementation, usually in software, of a protocol or other
+ procedure.
+
+more-fragments flag
+ A flag indicating whether or not this internet datagram
+ contains the end of an internet datagram, carried in the
+ internet header Flags field.
+
+NFB
+ The Number of Fragment Blocks in a the data portion of an
+ internet fragment. That is, the length of a portion of data
+ measured in 8 octet units.
+
+
+
+[Page 42]
+
+
+September 1981
+ Internet Protocol
+ Glossary
+
+
+
+octet
+ An eight bit byte.
+
+Options
+ The internet header Options field may contain several options,
+ and each option may be several octets in length.
+
+Padding
+ The internet header Padding field is used to ensure that the
+ data begins on 32 bit word boundary. The padding is zero.
+
+Protocol
+ In this document, the next higher level protocol identifier,
+ an internet header field.
+
+Rest
+ The local address portion of an Internet Address.
+
+Source
+ The source address, an internet header field.
+
+TCP
+ Transmission Control Protocol: A host-to-host protocol for
+ reliable communication in internet environments.
+
+TCP Segment
+ The unit of data exchanged between TCP modules (including the
+ TCP header).
+
+TFTP
+ Trivial File Transfer Protocol: A simple file transfer
+ protocol built on UDP.
+
+Time to Live
+ An internet header field which indicates the upper bound on
+ how long this internet datagram may exist.
+
+TOS
+ Type of Service
+
+Total Length
+ The internet header field Total Length is the length of the
+ datagram in octets including internet header and data.
+
+TTL
+ Time to Live
+
+
+
+
+ [Page 43]
+
+
+ September 1981
+Internet Protocol
+Glossary
+
+
+
+Type of Service
+ An internet header field which indicates the type (or quality)
+ of service for this internet datagram.
+
+UDP
+ User Datagram Protocol: A user level protocol for transaction
+ oriented applications.
+
+User
+ The user of the internet protocol. This may be a higher level
+ protocol module, an application program, or a gateway program.
+
+Version
+ The Version field indicates the format of the internet header.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 44]
+
+
+September 1981
+ Internet Protocol
+
+
+
+ REFERENCES
+
+
+
+[1] Cerf, V., "The Catenet Model for Internetworking," Information
+ Processing Techniques Office, Defense Advanced Research Projects
+ Agency, IEN 48, July 1978.
+
+[2] Bolt Beranek and Newman, "Specification for the Interconnection of
+ a Host and an IMP," BBN Technical Report 1822, Revised May 1978.
+
+[3] Postel, J., "Internet Control Message Protocol - DARPA Internet
+ Program Protocol Specification," RFC 792, USC/Information Sciences
+ Institute, September 1981.
+
+[4] Shoch, J., "Inter-Network Naming, Addressing, and Routing,"
+ COMPCON, IEEE Computer Society, Fall 1978.
+
+[5] Postel, J., "Address Mappings," RFC 796, USC/Information Sciences
+ Institute, September 1981.
+
+[6] Shoch, J., "Packet Fragmentation in Inter-Network Protocols,"
+ Computer Networks, v. 3, n. 1, February 1979.
+
+[7] Strazisar, V., "How to Build a Gateway", IEN 109, Bolt Beranek and
+ Newman, August 1979.
+
+[8] Postel, J., "Service Mappings," RFC 795, USC/Information Sciences
+ Institute, September 1981.
+
+[9] Postel, J., "Assigned Numbers," RFC 790, USC/Information Sciences
+ Institute, September 1981.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [Page 45]
+
diff --git a/rfc/rfc793.txt b/rfc/rfc793.txt
new file mode 100644
index 0000000..603a78c
--- /dev/null
+++ b/rfc/rfc793.txt
@@ -0,0 +1,5247 @@
+
+
+RFC: 793
+
+
+
+
+
+
+
+ TRANSMISSION CONTROL PROTOCOL
+
+
+ DARPA INTERNET PROGRAM
+
+ PROTOCOL SPECIFICATION
+
+
+
+ September 1981
+
+
+
+
+
+
+
+
+
+
+
+
+
+ prepared for
+
+ Defense Advanced Research Projects Agency
+ Information Processing Techniques Office
+ 1400 Wilson Boulevard
+ Arlington, Virginia 22209
+
+
+
+
+
+
+
+ by
+
+ Information Sciences Institute
+ University of Southern California
+ 4676 Admiralty Way
+ Marina del Rey, California 90291
+
+
+
+September 1981
+ Transmission Control Protocol
+
+
+
+ TABLE OF CONTENTS
+
+ PREFACE ........................................................ iii
+
+1. INTRODUCTION ..................................................... 1
+
+ 1.1 Motivation .................................................... 1
+ 1.2 Scope ......................................................... 2
+ 1.3 About This Document ........................................... 2
+ 1.4 Interfaces .................................................... 3
+ 1.5 Operation ..................................................... 3
+
+2. PHILOSOPHY ....................................................... 7
+
+ 2.1 Elements of the Internetwork System ........................... 7
+ 2.2 Model of Operation ............................................ 7
+ 2.3 The Host Environment .......................................... 8
+ 2.4 Interfaces .................................................... 9
+ 2.5 Relation to Other Protocols ................................... 9
+ 2.6 Reliable Communication ........................................ 9
+ 2.7 Connection Establishment and Clearing ........................ 10
+ 2.8 Data Communication ........................................... 12
+ 2.9 Precedence and Security ...................................... 13
+ 2.10 Robustness Principle ......................................... 13
+
+3. FUNCTIONAL SPECIFICATION ........................................ 15
+
+ 3.1 Header Format ................................................ 15
+ 3.2 Terminology .................................................. 19
+ 3.3 Sequence Numbers ............................................. 24
+ 3.4 Establishing a connection .................................... 30
+ 3.5 Closing a Connection ......................................... 37
+ 3.6 Precedence and Security ...................................... 40
+ 3.7 Data Communication ........................................... 40
+ 3.8 Interfaces ................................................... 44
+ 3.9 Event Processing ............................................. 52
+
+GLOSSARY ............................................................ 79
+
+REFERENCES .......................................................... 85
+
+
+
+
+
+
+
+
+
+
+
+ [Page i]
+
+
+ September 1981
+Transmission Control Protocol
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page ii]
+
+
+September 1981
+ Transmission Control Protocol
+
+
+
+ PREFACE
+
+
+
+This document describes the DoD Standard Transmission Control Protocol
+(TCP). There have been nine earlier editions of the ARPA TCP
+specification on which this standard is based, and the present text
+draws heavily from them. There have been many contributors to this work
+both in terms of concepts and in terms of text. This edition clarifies
+several details and removes the end-of-letter buffer-size adjustments,
+and redescribes the letter mechanism as a push function.
+
+ Jon Postel
+
+ Editor
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [Page iii]
+
+
+
+
+RFC: 793
+Replaces: RFC 761
+IENs: 129, 124, 112, 81,
+55, 44, 40, 27, 21, 5
+
+ TRANSMISSION CONTROL PROTOCOL
+
+ DARPA INTERNET PROGRAM
+ PROTOCOL SPECIFICATION
+
+
+
+ 1. INTRODUCTION
+
+The Transmission Control Protocol (TCP) is intended for use as a highly
+reliable host-to-host protocol between hosts in packet-switched computer
+communication networks, and in interconnected systems of such networks.
+
+This document describes the functions to be performed by the
+Transmission Control Protocol, the program that implements it, and its
+interface to programs or users that require its services.
+
+1.1. Motivation
+
+ Computer communication systems are playing an increasingly important
+ role in military, government, and civilian environments. This
+ document focuses its attention primarily on military computer
+ communication requirements, especially robustness in the presence of
+ communication unreliability and availability in the presence of
+ congestion, but many of these problems are found in the civilian and
+ government sector as well.
+
+ As strategic and tactical computer communication networks are
+ developed and deployed, it is essential to provide means of
+ interconnecting them and to provide standard interprocess
+ communication protocols which can support a broad range of
+ applications. In anticipation of the need for such standards, the
+ Deputy Undersecretary of Defense for Research and Engineering has
+ declared the Transmission Control Protocol (TCP) described herein to
+ be a basis for DoD-wide inter-process communication protocol
+ standardization.
+
+ TCP is a connection-oriented, end-to-end reliable protocol designed to
+ fit into a layered hierarchy of protocols which support multi-network
+ applications. The TCP provides for reliable inter-process
+ communication between pairs of processes in host computers attached to
+ distinct but interconnected computer communication networks. Very few
+ assumptions are made as to the reliability of the communication
+ protocols below the TCP layer. TCP assumes it can obtain a simple,
+ potentially unreliable datagram service from the lower level
+ protocols. In principle, the TCP should be able to operate above a
+ wide spectrum of communication systems ranging from hard-wired
+ connections to packet-switched or circuit-switched networks.
+
+
+ [Page 1]
+
+
+ September 1981
+Transmission Control Protocol
+Introduction
+
+
+
+ TCP is based on concepts first described by Cerf and Kahn in [1]. The
+ TCP fits into a layered protocol architecture just above a basic
+ Internet Protocol [2] which provides a way for the TCP to send and
+ receive variable-length segments of information enclosed in internet
+ datagram "envelopes". The internet datagram provides a means for
+ addressing source and destination TCPs in different networks. The
+ internet protocol also deals with any fragmentation or reassembly of
+ the TCP segments required to achieve transport and delivery through
+ multiple networks and interconnecting gateways. The internet protocol
+ also carries information on the precedence, security classification
+ and compartmentation of the TCP segments, so this information can be
+ communicated end-to-end across multiple networks.
+
+ Protocol Layering
+
+ +---------------------+
+ | higher-level |
+ +---------------------+
+ | TCP |
+ +---------------------+
+ | internet protocol |
+ +---------------------+
+ |communication network|
+ +---------------------+
+
+ Figure 1
+
+ Much of this document is written in the context of TCP implementations
+ which are co-resident with higher level protocols in the host
+ computer. Some computer systems will be connected to networks via
+ front-end computers which house the TCP and internet protocol layers,
+ as well as network specific software. The TCP specification describes
+ an interface to the higher level protocols which appears to be
+ implementable even for the front-end case, as long as a suitable
+ host-to-front end protocol is implemented.
+
+1.2. Scope
+
+ The TCP is intended to provide a reliable process-to-process
+ communication service in a multinetwork environment. The TCP is
+ intended to be a host-to-host protocol in common use in multiple
+ networks.
+
+1.3. About this Document
+
+ This document represents a specification of the behavior required of
+ any TCP implementation, both in its interactions with higher level
+ protocols and in its interactions with other TCPs. The rest of this
+
+
+[Page 2]
+
+
+September 1981
+ Transmission Control Protocol
+ Introduction
+
+
+
+ section offers a very brief view of the protocol interfaces and
+ operation. Section 2 summarizes the philosophical basis for the TCP
+ design. Section 3 offers both a detailed description of the actions
+ required of TCP when various events occur (arrival of new segments,
+ user calls, errors, etc.) and the details of the formats of TCP
+ segments.
+
+1.4. Interfaces
+
+ The TCP interfaces on one side to user or application processes and on
+ the other side to a lower level protocol such as Internet Protocol.
+
+ The interface between an application process and the TCP is
+ illustrated in reasonable detail. This interface consists of a set of
+ calls much like the calls an operating system provides to an
+ application process for manipulating files. For example, there are
+ calls to open and close connections and to send and receive data on
+ established connections. It is also expected that the TCP can
+ asynchronously communicate with application programs. Although
+ considerable freedom is permitted to TCP implementors to design
+ interfaces which are appropriate to a particular operating system
+ environment, a minimum functionality is required at the TCP/user
+ interface for any valid implementation.
+
+ The interface between TCP and lower level protocol is essentially
+ unspecified except that it is assumed there is a mechanism whereby the
+ two levels can asynchronously pass information to each other.
+ Typically, one expects the lower level protocol to specify this
+ interface. TCP is designed to work in a very general environment of
+ interconnected networks. The lower level protocol which is assumed
+ throughout this document is the Internet Protocol [2].
+
+1.5. Operation
+
+ As noted above, the primary purpose of the TCP is to provide reliable,
+ securable logical circuit or connection service between pairs of
+ processes. To provide this service on top of a less reliable internet
+ communication system requires facilities in the following areas:
+
+ Basic Data Transfer
+ Reliability
+ Flow Control
+ Multiplexing
+ Connections
+ Precedence and Security
+
+ The basic operation of the TCP in each of these areas is described in
+ the following paragraphs.
+
+
+ [Page 3]
+
+
+ September 1981
+Transmission Control Protocol
+Introduction
+
+
+
+ Basic Data Transfer:
+
+ The TCP is able to transfer a continuous stream of octets in each
+ direction between its users by packaging some number of octets into
+ segments for transmission through the internet system. In general,
+ the TCPs decide when to block and forward data at their own
+ convenience.
+
+ Sometimes users need to be sure that all the data they have
+ submitted to the TCP has been transmitted. For this purpose a push
+ function is defined. To assure that data submitted to a TCP is
+ actually transmitted the sending user indicates that it should be
+ pushed through to the receiving user. A push causes the TCPs to
+ promptly forward and deliver data up to that point to the receiver.
+ The exact push point might not be visible to the receiving user and
+ the push function does not supply a record boundary marker.
+
+ Reliability:
+
+ The TCP must recover from data that is damaged, lost, duplicated, or
+ delivered out of order by the internet communication system. This
+ is achieved by assigning a sequence number to each octet
+ transmitted, and requiring a positive acknowledgment (ACK) from the
+ receiving TCP. If the ACK is not received within a timeout
+ interval, the data is retransmitted. At the receiver, the sequence
+ numbers are used to correctly order segments that may be received
+ out of order and to eliminate duplicates. Damage is handled by
+ adding a checksum to each segment transmitted, checking it at the
+ receiver, and discarding damaged segments.
+
+ As long as the TCPs continue to function properly and the internet
+ system does not become completely partitioned, no transmission
+ errors will affect the correct delivery of data. TCP recovers from
+ internet communication system errors.
+
+ Flow Control:
+
+ TCP provides a means for the receiver to govern the amount of data
+ sent by the sender. This is achieved by returning a "window" with
+ every ACK indicating a range of acceptable sequence numbers beyond
+ the last segment successfully received. The window indicates an
+ allowed number of octets that the sender may transmit before
+ receiving further permission.
+
+
+
+
+
+
+
+[Page 4]
+
+
+September 1981
+ Transmission Control Protocol
+ Introduction
+
+
+
+ Multiplexing:
+
+ To allow for many processes within a single Host to use TCP
+ communication facilities simultaneously, the TCP provides a set of
+ addresses or ports within each host. Concatenated with the network
+ and host addresses from the internet communication layer, this forms
+ a socket. A pair of sockets uniquely identifies each connection.
+ That is, a socket may be simultaneously used in multiple
+ connections.
+
+ The binding of ports to processes is handled independently by each
+ Host. However, it proves useful to attach frequently used processes
+ (e.g., a "logger" or timesharing service) to fixed sockets which are
+ made known to the public. These services can then be accessed
+ through the known addresses. Establishing and learning the port
+ addresses of other processes may involve more dynamic mechanisms.
+
+ Connections:
+
+ The reliability and flow control mechanisms described above require
+ that TCPs initialize and maintain certain status information for
+ each data stream. The combination of this information, including
+ sockets, sequence numbers, and window sizes, is called a connection.
+ Each connection is uniquely specified by a pair of sockets
+ identifying its two sides.
+
+ When two processes wish to communicate, their TCP's must first
+ establish a connection (initialize the status information on each
+ side). When their communication is complete, the connection is
+ terminated or closed to free the resources for other uses.
+
+ Since connections must be established between unreliable hosts and
+ over the unreliable internet communication system, a handshake
+ mechanism with clock-based sequence numbers is used to avoid
+ erroneous initialization of connections.
+
+ Precedence and Security:
+
+ The users of TCP may indicate the security and precedence of their
+ communication. Provision is made for default values to be used when
+ these features are not needed.
+
+
+
+
+
+
+
+
+
+ [Page 5]
+
+
+ September 1981
+Transmission Control Protocol
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 6]
+
+
+September 1981
+ Transmission Control Protocol
+
+
+
+ 2. PHILOSOPHY
+
+2.1. Elements of the Internetwork System
+
+ The internetwork environment consists of hosts connected to networks
+ which are in turn interconnected via gateways. It is assumed here
+ that the networks may be either local networks (e.g., the ETHERNET) or
+ large networks (e.g., the ARPANET), but in any case are based on
+ packet switching technology. The active agents that produce and
+ consume messages are processes. Various levels of protocols in the
+ networks, the gateways, and the hosts support an interprocess
+ communication system that provides two-way data flow on logical
+ connections between process ports.
+
+ The term packet is used generically here to mean the data of one
+ transaction between a host and its network. The format of data blocks
+ exchanged within the a network will generally not be of concern to us.
+
+ Hosts are computers attached to a network, and from the communication
+ network's point of view, are the sources and destinations of packets.
+ Processes are viewed as the active elements in host computers (in
+ accordance with the fairly common definition of a process as a program
+ in execution). Even terminals and files or other I/O devices are
+ viewed as communicating with each other through the use of processes.
+ Thus, all communication is viewed as inter-process communication.
+
+ Since a process may need to distinguish among several communication
+ streams between itself and another process (or processes), we imagine
+ that each process may have a number of ports through which it
+ communicates with the ports of other processes.
+
+2.2. Model of Operation
+
+ Processes transmit data by calling on the TCP and passing buffers of
+ data as arguments. The TCP packages the data from these buffers into
+ segments and calls on the internet module to transmit each segment to
+ the destination TCP. The receiving TCP places the data from a segment
+ into the receiving user's buffer and notifies the receiving user. The
+ TCPs include control information in the segments which they use to
+ ensure reliable ordered data transmission.
+
+ The model of internet communication is that there is an internet
+ protocol module associated with each TCP which provides an interface
+ to the local network. This internet module packages TCP segments
+ inside internet datagrams and routes these datagrams to a destination
+ internet module or intermediate gateway. To transmit the datagram
+ through the local network, it is embedded in a local network packet.
+
+ The packet switches may perform further packaging, fragmentation, or
+
+
+ [Page 7]
+
+
+ September 1981
+Transmission Control Protocol
+Philosophy
+
+
+
+ other operations to achieve the delivery of the local packet to the
+ destination internet module.
+
+ At a gateway between networks, the internet datagram is "unwrapped"
+ from its local packet and examined to determine through which network
+ the internet datagram should travel next. The internet datagram is
+ then "wrapped" in a local packet suitable to the next network and
+ routed to the next gateway, or to the final destination.
+
+ A gateway is permitted to break up an internet datagram into smaller
+ internet datagram fragments if this is necessary for transmission
+ through the next network. To do this, the gateway produces a set of
+ internet datagrams; each carrying a fragment. Fragments may be
+ further broken into smaller fragments at subsequent gateways. The
+ internet datagram fragment format is designed so that the destination
+ internet module can reassemble fragments into internet datagrams.
+
+ A destination internet module unwraps the segment from the datagram
+ (after reassembling the datagram, if necessary) and passes it to the
+ destination TCP.
+
+ This simple model of the operation glosses over many details. One
+ important feature is the type of service. This provides information
+ to the gateway (or internet module) to guide it in selecting the
+ service parameters to be used in traversing the next network.
+ Included in the type of service information is the precedence of the
+ datagram. Datagrams may also carry security information to permit
+ host and gateways that operate in multilevel secure environments to
+ properly segregate datagrams for security considerations.
+
+2.3. The Host Environment
+
+ The TCP is assumed to be a module in an operating system. The users
+ access the TCP much like they would access the file system. The TCP
+ may call on other operating system functions, for example, to manage
+ data structures. The actual interface to the network is assumed to be
+ controlled by a device driver module. The TCP does not call on the
+ network device driver directly, but rather calls on the internet
+ datagram protocol module which may in turn call on the device driver.
+
+ The mechanisms of TCP do not preclude implementation of the TCP in a
+ front-end processor. However, in such an implementation, a
+ host-to-front-end protocol must provide the functionality to support
+ the type of TCP-user interface described in this document.
+
+
+
+
+
+
+[Page 8]
+
+
+September 1981
+ Transmission Control Protocol
+ Philosophy
+
+
+
+2.4. Interfaces
+
+ The TCP/user interface provides for calls made by the user on the TCP
+ to OPEN or CLOSE a connection, to SEND or RECEIVE data, or to obtain
+ STATUS about a connection. These calls are like other calls from user
+ programs on the operating system, for example, the calls to open, read
+ from, and close a file.
+
+ The TCP/internet interface provides calls to send and receive
+ datagrams addressed to TCP modules in hosts anywhere in the internet
+ system. These calls have parameters for passing the address, type of
+ service, precedence, security, and other control information.
+
+2.5. Relation to Other Protocols
+
+ The following diagram illustrates the place of the TCP in the protocol
+ hierarchy:
+
+
+ +------+ +-----+ +-----+ +-----+
+ |Telnet| | FTP | |Voice| ... | | Application Level
+ +------+ +-----+ +-----+ +-----+
+ | | | |
+ +-----+ +-----+ +-----+
+ | TCP | | RTP | ... | | Host Level
+ +-----+ +-----+ +-----+
+ | | |
+ +-------------------------------+
+ | Internet Protocol & ICMP | Gateway Level
+ +-------------------------------+
+ |
+ +---------------------------+
+ | Local Network Protocol | Network Level
+ +---------------------------+
+
+ Protocol Relationships
+
+ Figure 2.
+
+ It is expected that the TCP will be able to support higher level
+ protocols efficiently. It should be easy to interface higher level
+ protocols like the ARPANET Telnet or AUTODIN II THP to the TCP.
+
+2.6. Reliable Communication
+
+ A stream of data sent on a TCP connection is delivered reliably and in
+ order at the destination.
+
+
+
+ [Page 9]
+
+
+ September 1981
+Transmission Control Protocol
+Philosophy
+
+
+
+ Transmission is made reliable via the use of sequence numbers and
+ acknowledgments. Conceptually, each octet of data is assigned a
+ sequence number. The sequence number of the first octet of data in a
+ segment is transmitted with that segment and is called the segment
+ sequence number. Segments also carry an acknowledgment number which
+ is the sequence number of the next expected data octet of
+ transmissions in the reverse direction. When the TCP transmits a
+ segment containing data, it puts a copy on a retransmission queue and
+ starts a timer; when the acknowledgment for that data is received, the
+ segment is deleted from the queue. If the acknowledgment is not
+ received before the timer runs out, the segment is retransmitted.
+
+ An acknowledgment by TCP does not guarantee that the data has been
+ delivered to the end user, but only that the receiving TCP has taken
+ the responsibility to do so.
+
+ To govern the flow of data between TCPs, a flow control mechanism is
+ employed. The receiving TCP reports a "window" to the sending TCP.
+ This window specifies the number of octets, starting with the
+ acknowledgment number, that the receiving TCP is currently prepared to
+ receive.
+
+2.7. Connection Establishment and Clearing
+
+ To identify the separate data streams that a TCP may handle, the TCP
+ provides a port identifier. Since port identifiers are selected
+ independently by each TCP they might not be unique. To provide for
+ unique addresses within each TCP, we concatenate an internet address
+ identifying the TCP with a port identifier to create a socket which
+ will be unique throughout all networks connected together.
+
+ A connection is fully specified by the pair of sockets at the ends. A
+ local socket may participate in many connections to different foreign
+ sockets. A connection can be used to carry data in both directions,
+ that is, it is "full duplex".
+
+ TCPs are free to associate ports with processes however they choose.
+ However, several basic concepts are necessary in any implementation.
+ There must be well-known sockets which the TCP associates only with
+ the "appropriate" processes by some means. We envision that processes
+ may "own" ports, and that processes can initiate connections only on
+ the ports they own. (Means for implementing ownership is a local
+ issue, but we envision a Request Port user command, or a method of
+ uniquely allocating a group of ports to a given process, e.g., by
+ associating the high order bits of a port name with a given process.)
+
+ A connection is specified in the OPEN call by the local port and
+ foreign socket arguments. In return, the TCP supplies a (short) local
+
+
+[Page 10]
+
+
+September 1981
+ Transmission Control Protocol
+ Philosophy
+
+
+
+ connection name by which the user refers to the connection in
+ subsequent calls. There are several things that must be remembered
+ about a connection. To store this information we imagine that there
+ is a data structure called a Transmission Control Block (TCB). One
+ implementation strategy would have the local connection name be a
+ pointer to the TCB for this connection. The OPEN call also specifies
+ whether the connection establishment is to be actively pursued, or to
+ be passively waited for.
+
+ A passive OPEN request means that the process wants to accept incoming
+ connection requests rather than attempting to initiate a connection.
+ Often the process requesting a passive OPEN will accept a connection
+ request from any caller. In this case a foreign socket of all zeros
+ is used to denote an unspecified socket. Unspecified foreign sockets
+ are allowed only on passive OPENs.
+
+ A service process that wished to provide services for unknown other
+ processes would issue a passive OPEN request with an unspecified
+ foreign socket. Then a connection could be made with any process that
+ requested a connection to this local socket. It would help if this
+ local socket were known to be associated with this service.
+
+ Well-known sockets are a convenient mechanism for a priori associating
+ a socket address with a standard service. For instance, the
+ "Telnet-Server" process is permanently assigned to a particular
+ socket, and other sockets are reserved for File Transfer, Remote Job
+ Entry, Text Generator, Echoer, and Sink processes (the last three
+ being for test purposes). A socket address might be reserved for
+ access to a "Look-Up" service which would return the specific socket
+ at which a newly created service would be provided. The concept of a
+ well-known socket is part of the TCP specification, but the assignment
+ of sockets to services is outside this specification. (See [4].)
+
+ Processes can issue passive OPENs and wait for matching active OPENs
+ from other processes and be informed by the TCP when connections have
+ been established. Two processes which issue active OPENs to each
+ other at the same time will be correctly connected. This flexibility
+ is critical for the support of distributed computing in which
+ components act asynchronously with respect to each other.
+
+ There are two principal cases for matching the sockets in the local
+ passive OPENs and an foreign active OPENs. In the first case, the
+ local passive OPENs has fully specified the foreign socket. In this
+ case, the match must be exact. In the second case, the local passive
+ OPENs has left the foreign socket unspecified. In this case, any
+ foreign socket is acceptable as long as the local sockets match.
+ Other possibilities include partially restricted matches.
+
+
+
+ [Page 11]
+
+
+ September 1981
+Transmission Control Protocol
+Philosophy
+
+
+
+ If there are several pending passive OPENs (recorded in TCBs) with the
+ same local socket, an foreign active OPEN will be matched to a TCB
+ with the specific foreign socket in the foreign active OPEN, if such a
+ TCB exists, before selecting a TCB with an unspecified foreign socket.
+
+ The procedures to establish connections utilize the synchronize (SYN)
+ control flag and involves an exchange of three messages. This
+ exchange has been termed a three-way hand shake [3].
+
+ A connection is initiated by the rendezvous of an arriving segment
+ containing a SYN and a waiting TCB entry each created by a user OPEN
+ command. The matching of local and foreign sockets determines when a
+ connection has been initiated. The connection becomes "established"
+ when sequence numbers have been synchronized in both directions.
+
+ The clearing of a connection also involves the exchange of segments,
+ in this case carrying the FIN control flag.
+
+2.8. Data Communication
+
+ The data that flows on a connection may be thought of as a stream of
+ octets. The sending user indicates in each SEND call whether the data
+ in that call (and any preceeding calls) should be immediately pushed
+ through to the receiving user by the setting of the PUSH flag.
+
+ A sending TCP is allowed to collect data from the sending user and to
+ send that data in segments at its own convenience, until the push
+ function is signaled, then it must send all unsent data. When a
+ receiving TCP sees the PUSH flag, it must not wait for more data from
+ the sending TCP before passing the data to the receiving process.
+
+ There is no necessary relationship between push functions and segment
+ boundaries. The data in any particular segment may be the result of a
+ single SEND call, in whole or part, or of multiple SEND calls.
+
+ The purpose of push function and the PUSH flag is to push data through
+ from the sending user to the receiving user. It does not provide a
+ record service.
+
+ There is a coupling between the push function and the use of buffers
+ of data that cross the TCP/user interface. Each time a PUSH flag is
+ associated with data placed into the receiving user's buffer, the
+ buffer is returned to the user for processing even if the buffer is
+ not filled. If data arrives that fills the user's buffer before a
+ PUSH is seen, the data is passed to the user in buffer size units.
+
+ TCP also provides a means to communicate to the receiver of data that
+ at some point further along in the data stream than the receiver is
+
+
+[Page 12]
+
+
+September 1981
+ Transmission Control Protocol
+ Philosophy
+
+
+
+ currently reading there is urgent data. TCP does not attempt to
+ define what the user specifically does upon being notified of pending
+ urgent data, but the general notion is that the receiving process will
+ take action to process the urgent data quickly.
+
+2.9. Precedence and Security
+
+ The TCP makes use of the internet protocol type of service field and
+ security option to provide precedence and security on a per connection
+ basis to TCP users. Not all TCP modules will necessarily function in
+ a multilevel secure environment; some may be limited to unclassified
+ use only, and others may operate at only one security level and
+ compartment. Consequently, some TCP implementations and services to
+ users may be limited to a subset of the multilevel secure case.
+
+ TCP modules which operate in a multilevel secure environment must
+ properly mark outgoing segments with the security, compartment, and
+ precedence. Such TCP modules must also provide to their users or
+ higher level protocols such as Telnet or THP an interface to allow
+ them to specify the desired security level, compartment, and
+ precedence of connections.
+
+2.10. Robustness Principle
+
+ TCP implementations will follow a general principle of robustness: be
+ conservative in what you do, be liberal in what you accept from
+ others.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [Page 13]
+
+
+ September 1981
+Transmission Control Protocol
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 14]
+
+
+September 1981
+ Transmission Control Protocol
+
+
+
+ 3. FUNCTIONAL SPECIFICATION
+
+3.1. Header Format
+
+ TCP segments are sent as internet datagrams. The Internet Protocol
+ header carries several information fields, including the source and
+ destination host addresses [2]. A TCP header follows the internet
+ header, supplying information specific to the TCP protocol. This
+ division allows for the existence of host level protocols other than
+ TCP.
+
+ TCP Header Format
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Source Port | Destination Port |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Sequence Number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Acknowledgment Number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Data | |U|A|P|R|S|F| |
+ | Offset| Reserved |R|C|S|S|Y|I| Window |
+ | | |G|K|H|T|N|N| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Checksum | Urgent Pointer |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Options | Padding |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ TCP Header Format
+
+ Note that one tick mark represents one bit position.
+
+ Figure 3.
+
+ Source Port: 16 bits
+
+ The source port number.
+
+ Destination Port: 16 bits
+
+ The destination port number.
+
+
+
+
+ [Page 15]
+
+
+ September 1981
+Transmission Control Protocol
+Functional Specification
+
+
+
+ Sequence Number: 32 bits
+
+ The sequence number of the first data octet in this segment (except
+ when SYN is present). If SYN is present the sequence number is the
+ initial sequence number (ISN) and the first data octet is ISN+1.
+
+ Acknowledgment Number: 32 bits
+
+ If the ACK control bit is set this field contains the value of the
+ next sequence number the sender of the segment is expecting to
+ receive. Once a connection is established this is always sent.
+
+ Data Offset: 4 bits
+
+ The number of 32 bit words in the TCP Header. This indicates where
+ the data begins. The TCP header (even one including options) is an
+ integral number of 32 bits long.
+
+ Reserved: 6 bits
+
+ Reserved for future use. Must be zero.
+
+ Control Bits: 6 bits (from left to right):
+
+ URG: Urgent Pointer field significant
+ ACK: Acknowledgment field significant
+ PSH: Push Function
+ RST: Reset the connection
+ SYN: Synchronize sequence numbers
+ FIN: No more data from sender
+
+ Window: 16 bits
+
+ The number of data octets beginning with the one indicated in the
+ acknowledgment field which the sender of this segment is willing to
+ accept.
+
+ Checksum: 16 bits
+
+ The checksum field is the 16 bit one's complement of the one's
+ complement sum of all 16 bit words in the header and text. If a
+ segment contains an odd number of header and text octets to be
+ checksummed, the last octet is padded on the right with zeros to
+ form a 16 bit word for checksum purposes. The pad is not
+ transmitted as part of the segment. While computing the checksum,
+ the checksum field itself is replaced with zeros.
+
+ The checksum also covers a 96 bit pseudo header conceptually
+
+
+[Page 16]
+
+
+September 1981
+ Transmission Control Protocol
+ Functional Specification
+
+
+
+ prefixed to the TCP header. This pseudo header contains the Source
+ Address, the Destination Address, the Protocol, and TCP length.
+ This gives the TCP protection against misrouted segments. This
+ information is carried in the Internet Protocol and is transferred
+ across the TCP/Network interface in the arguments or results of
+ calls by the TCP on the IP.
+
+ +--------+--------+--------+--------+
+ | Source Address |
+ +--------+--------+--------+--------+
+ | Destination Address |
+ +--------+--------+--------+--------+
+ | zero | PTCL | TCP Length |
+ +--------+--------+--------+--------+
+
+ The TCP Length is the TCP header length plus the data length in
+ octets (this is not an explicitly transmitted quantity, but is
+ computed), and it does not count the 12 octets of the pseudo
+ header.
+
+ Urgent Pointer: 16 bits
+
+ This field communicates the current value of the urgent pointer as a
+ positive offset from the sequence number in this segment. The
+ urgent pointer points to the sequence number of the octet following
+ the urgent data. This field is only be interpreted in segments with
+ the URG control bit set.
+
+ Options: variable
+
+ Options may occupy space at the end of the TCP header and are a
+ multiple of 8 bits in length. All options are included in the
+ checksum. An option may begin on any octet boundary. There are two
+ cases for the format of an option:
+
+ Case 1: A single octet of option-kind.
+
+ Case 2: An octet of option-kind, an octet of option-length, and
+ the actual option-data octets.
+
+ The option-length counts the two octets of option-kind and
+ option-length as well as the option-data octets.
+
+ Note that the list of options may be shorter than the data offset
+ field might imply. The content of the header beyond the
+ End-of-Option option must be header padding (i.e., zero).
+
+ A TCP must implement all options.
+
+
+ [Page 17]
+
+
+ September 1981
+Transmission Control Protocol
+Functional Specification
+
+
+
+ Currently defined options include (kind indicated in octal):
+
+ Kind Length Meaning
+ ---- ------ -------
+ 0 - End of option list.
+ 1 - No-Operation.
+ 2 4 Maximum Segment Size.
+
+
+ Specific Option Definitions
+
+ End of Option List
+
+ +--------+
+ |00000000|
+ +--------+
+ Kind=0
+
+ This option code indicates the end of the option list. This
+ might not coincide with the end of the TCP header according to
+ the Data Offset field. This is used at the end of all options,
+ not the end of each option, and need only be used if the end of
+ the options would not otherwise coincide with the end of the TCP
+ header.
+
+ No-Operation
+
+ +--------+
+ |00000001|
+ +--------+
+ Kind=1
+
+ This option code may be used between options, for example, to
+ align the beginning of a subsequent option on a word boundary.
+ There is no guarantee that senders will use this option, so
+ receivers must be prepared to process options even if they do
+ not begin on a word boundary.
+
+ Maximum Segment Size
+
+ +--------+--------+---------+--------+
+ |00000010|00000100| max seg size |
+ +--------+--------+---------+--------+
+ Kind=2 Length=4
+
+
+
+
+
+
+[Page 18]
+
+
+September 1981
+ Transmission Control Protocol
+ Functional Specification
+
+
+
+ Maximum Segment Size Option Data: 16 bits
+
+ If this option is present, then it communicates the maximum
+ receive segment size at the TCP which sends this segment.
+ This field must only be sent in the initial connection request
+ (i.e., in segments with the SYN control bit set). If this
+ option is not used, any segment size is allowed.
+
+ Padding: variable
+
+ The TCP header padding is used to ensure that the TCP header ends
+ and data begins on a 32 bit boundary. The padding is composed of
+ zeros.
+
+3.2. Terminology
+
+ Before we can discuss very much about the operation of the TCP we need
+ to introduce some detailed terminology. The maintenance of a TCP
+ connection requires the remembering of several variables. We conceive
+ of these variables being stored in a connection record called a
+ Transmission Control Block or TCB. Among the variables stored in the
+ TCB are the local and remote socket numbers, the security and
+ precedence of the connection, pointers to the user's send and receive
+ buffers, pointers to the retransmit queue and to the current segment.
+ In addition several variables relating to the send and receive
+ sequence numbers are stored in the TCB.
+
+ Send Sequence Variables
+
+ SND.UNA - send unacknowledged
+ SND.NXT - send next
+ SND.WND - send window
+ SND.UP - send urgent pointer
+ SND.WL1 - segment sequence number used for last window update
+ SND.WL2 - segment acknowledgment number used for last window
+ update
+ ISS - initial send sequence number
+
+ Receive Sequence Variables
+
+ RCV.NXT - receive next
+ RCV.WND - receive window
+ RCV.UP - receive urgent pointer
+ IRS - initial receive sequence number
+
+
+
+
+
+
+ [Page 19]
+
+
+ September 1981
+Transmission Control Protocol
+Functional Specification
+
+
+
+ The following diagrams may help to relate some of these variables to
+ the sequence space.
+
+ Send Sequence Space
+
+ 1 2 3 4
+ ----------|----------|----------|----------
+ SND.UNA SND.NXT SND.UNA
+ +SND.WND
+
+ 1 - old sequence numbers which have been acknowledged
+ 2 - sequence numbers of unacknowledged data
+ 3 - sequence numbers allowed for new data transmission
+ 4 - future sequence numbers which are not yet allowed
+
+ Send Sequence Space
+
+ Figure 4.
+
+
+
+ The send window is the portion of the sequence space labeled 3 in
+ figure 4.
+
+ Receive Sequence Space
+
+ 1 2 3
+ ----------|----------|----------
+ RCV.NXT RCV.NXT
+ +RCV.WND
+
+ 1 - old sequence numbers which have been acknowledged
+ 2 - sequence numbers allowed for new reception
+ 3 - future sequence numbers which are not yet allowed
+
+ Receive Sequence Space
+
+ Figure 5.
+
+
+
+ The receive window is the portion of the sequence space labeled 2 in
+ figure 5.
+
+ There are also some variables used frequently in the discussion that
+ take their values from the fields of the current segment.
+
+
+
+
+[Page 20]
+
+
+September 1981
+ Transmission Control Protocol
+ Functional Specification
+
+
+
+ Current Segment Variables
+
+ SEG.SEQ - segment sequence number
+ SEG.ACK - segment acknowledgment number
+ SEG.LEN - segment length
+ SEG.WND - segment window
+ SEG.UP - segment urgent pointer
+ SEG.PRC - segment precedence value
+
+ A connection progresses through a series of states during its
+ lifetime. The states are: LISTEN, SYN-SENT, SYN-RECEIVED,
+ ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK,
+ TIME-WAIT, and the fictional state CLOSED. CLOSED is fictional
+ because it represents the state when there is no TCB, and therefore,
+ no connection. Briefly the meanings of the states are:
+
+ LISTEN - represents waiting for a connection request from any remote
+ TCP and port.
+
+ SYN-SENT - represents waiting for a matching connection request
+ after having sent a connection request.
+
+ SYN-RECEIVED - represents waiting for a confirming connection
+ request acknowledgment after having both received and sent a
+ connection request.
+
+ ESTABLISHED - represents an open connection, data received can be
+ delivered to the user. The normal state for the data transfer phase
+ of the connection.
+
+ FIN-WAIT-1 - represents waiting for a connection termination request
+ from the remote TCP, or an acknowledgment of the connection
+ termination request previously sent.
+
+ FIN-WAIT-2 - represents waiting for a connection termination request
+ from the remote TCP.
+
+ CLOSE-WAIT - represents waiting for a connection termination request
+ from the local user.
+
+ CLOSING - represents waiting for a connection termination request
+ acknowledgment from the remote TCP.
+
+ LAST-ACK - represents waiting for an acknowledgment of the
+ connection termination request previously sent to the remote TCP
+ (which includes an acknowledgment of its connection termination
+ request).
+
+
+
+ [Page 21]
+
+
+ September 1981
+Transmission Control Protocol
+Functional Specification
+
+
+
+ TIME-WAIT - represents waiting for enough time to pass to be sure
+ the remote TCP received the acknowledgment of its connection
+ termination request.
+
+ CLOSED - represents no connection state at all.
+
+ A TCP connection progresses from one state to another in response to
+ events. The events are the user calls, OPEN, SEND, RECEIVE, CLOSE,
+ ABORT, and STATUS; the incoming segments, particularly those
+ containing the SYN, ACK, RST and FIN flags; and timeouts.
+
+ The state diagram in figure 6 illustrates only state changes, together
+ with the causing events and resulting actions, but addresses neither
+ error conditions nor actions which are not connected with state
+ changes. In a later section, more detail is offered with respect to
+ the reaction of the TCP to events.
+
+ NOTE BENE: this diagram is only a summary and must not be taken as
+ the total specification.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 22]
+
+
+September 1981
+ Transmission Control Protocol
+ Functional Specification
+
+
+
+
+ +---------+ ---------\ active OPEN
+ | CLOSED | \ -----------
+ +---------+<---------\ \ create TCB
+ | ^ \ \ snd SYN
+ passive OPEN | | CLOSE \ \
+ ------------ | | ---------- \ \
+ create TCB | | delete TCB \ \
+ V | \ \
+ +---------+ CLOSE | \
+ | LISTEN | ---------- | |
+ +---------+ delete TCB | |
+ rcv SYN | | SEND | |
+ ----------- | | ------- | V
+ +---------+ snd SYN,ACK / \ snd SYN +---------+
+ | |<----------------- ------------------>| |
+ | SYN | rcv SYN | SYN |
+ | RCVD |<-----------------------------------------------| SENT |
+ | | snd ACK | |
+ | |------------------ -------------------| |
+ +---------+ rcv ACK of SYN \ / rcv SYN,ACK +---------+
+ | -------------- | | -----------
+ | x | | snd ACK
+ | V V
+ | CLOSE +---------+
+ | ------- | ESTAB |
+ | snd FIN +---------+
+ | CLOSE | | rcv FIN
+ V ------- | | -------
+ +---------+ snd FIN / \ snd ACK +---------+
+ | FIN |<----------------- ------------------>| CLOSE |
+ | WAIT-1 |------------------ | WAIT |
+ +---------+ rcv FIN \ +---------+
+ | rcv ACK of FIN ------- | CLOSE |
+ | -------------- snd ACK | ------- |
+ V x V snd FIN V
+ +---------+ +---------+ +---------+
+ |FINWAIT-2| | CLOSING | | LAST-ACK|
+ +---------+ +---------+ +---------+
+ | rcv ACK of FIN | rcv ACK of FIN |
+ | rcv FIN -------------- | Timeout=2MSL -------------- |
+ | ------- x V ------------ x V
+ \ snd ACK +---------+delete TCB +---------+
+ ------------------------>|TIME WAIT|------------------>| CLOSED |
+ +---------+ +---------+
+
+ TCP Connection State Diagram
+ Figure 6.
+
+
+ [Page 23]
+
+
+ September 1981
+Transmission Control Protocol
+Functional Specification
+
+
+
+3.3. Sequence Numbers
+
+ A fundamental notion in the design is that every octet of data sent
+ over a TCP connection has a sequence number. Since every octet is
+ sequenced, each of them can be acknowledged. The acknowledgment
+ mechanism employed is cumulative so that an acknowledgment of sequence
+ number X indicates that all octets up to but not including X have been
+ received. This mechanism allows for straight-forward duplicate
+ detection in the presence of retransmission. Numbering of octets
+ within a segment is that the first data octet immediately following
+ the header is the lowest numbered, and the following octets are
+ numbered consecutively.
+
+ It is essential to remember that the actual sequence number space is
+ finite, though very large. This space ranges from 0 to 2**32 - 1.
+ Since the space is finite, all arithmetic dealing with sequence
+ numbers must be performed modulo 2**32. This unsigned arithmetic
+ preserves the relationship of sequence numbers as they cycle from
+ 2**32 - 1 to 0 again. There are some subtleties to computer modulo
+ arithmetic, so great care should be taken in programming the
+ comparison of such values. The symbol "=<" means "less than or equal"
+ (modulo 2**32).
+
+ The typical kinds of sequence number comparisons which the TCP must
+ perform include:
+
+ (a) Determining that an acknowledgment refers to some sequence
+ number sent but not yet acknowledged.
+
+ (b) Determining that all sequence numbers occupied by a segment
+ have been acknowledged (e.g., to remove the segment from a
+ retransmission queue).
+
+ (c) Determining that an incoming segment contains sequence numbers
+ which are expected (i.e., that the segment "overlaps" the
+ receive window).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 24]
+
+
+September 1981
+ Transmission Control Protocol
+ Functional Specification
+
+
+
+ In response to sending data the TCP will receive acknowledgments. The
+ following comparisons are needed to process the acknowledgments.
+
+ SND.UNA = oldest unacknowledged sequence number
+
+ SND.NXT = next sequence number to be sent
+
+ SEG.ACK = acknowledgment from the receiving TCP (next sequence
+ number expected by the receiving TCP)
+
+ SEG.SEQ = first sequence number of a segment
+
+ SEG.LEN = the number of octets occupied by the data in the segment
+ (counting SYN and FIN)
+
+ SEG.SEQ+SEG.LEN-1 = last sequence number of a segment
+
+ A new acknowledgment (called an "acceptable ack"), is one for which
+ the inequality below holds:
+
+ SND.UNA < SEG.ACK =< SND.NXT
+
+ A segment on the retransmission queue is fully acknowledged if the sum
+ of its sequence number and length is less or equal than the
+ acknowledgment value in the incoming segment.
+
+ When data is received the following comparisons are needed:
+
+ RCV.NXT = next sequence number expected on an incoming segments, and
+ is the left or lower edge of the receive window
+
+ RCV.NXT+RCV.WND-1 = last sequence number expected on an incoming
+ segment, and is the right or upper edge of the receive window
+
+ SEG.SEQ = first sequence number occupied by the incoming segment
+
+ SEG.SEQ+SEG.LEN-1 = last sequence number occupied by the incoming
+ segment
+
+ A segment is judged to occupy a portion of valid receive sequence
+ space if
+
+ RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND
+
+ or
+
+ RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND
+
+
+
+ [Page 25]
+
+
+ September 1981
+Transmission Control Protocol
+Functional Specification
+
+
+
+ The first part of this test checks to see if the beginning of the
+ segment falls in the window, the second part of the test checks to see
+ if the end of the segment falls in the window; if the segment passes
+ either part of the test it contains data in the window.
+
+ Actually, it is a little more complicated than this. Due to zero
+ windows and zero length segments, we have four cases for the
+ acceptability of an incoming segment:
+
+ Segment Receive Test
+ Length Window
+ ------- ------- -------------------------------------------
+
+ 0 0 SEG.SEQ = RCV.NXT
+
+ 0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND
+
+ >0 0 not acceptable
+
+ >0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND
+ or RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND
+
+ Note that when the receive window is zero no segments should be
+ acceptable except ACK segments. Thus, it is be possible for a TCP to
+ maintain a zero receive window while transmitting data and receiving
+ ACKs. However, even when the receive window is zero, a TCP must
+ process the RST and URG fields of all incoming segments.
+
+ We have taken advantage of the numbering scheme to protect certain
+ control information as well. This is achieved by implicitly including
+ some control flags in the sequence space so they can be retransmitted
+ and acknowledged without confusion (i.e., one and only one copy of the
+ control will be acted upon). Control information is not physically
+ carried in the segment data space. Consequently, we must adopt rules
+ for implicitly assigning sequence numbers to control. The SYN and FIN
+ are the only controls requiring this protection, and these controls
+ are used only at connection opening and closing. For sequence number
+ purposes, the SYN is considered to occur before the first actual data
+ octet of the segment in which it occurs, while the FIN is considered
+ to occur after the last actual data octet in a segment in which it
+ occurs. The segment length (SEG.LEN) includes both data and sequence
+ space occupying controls. When a SYN is present then SEG.SEQ is the
+ sequence number of the SYN.
+
+
+
+
+
+
+
+[Page 26]
+
+
+September 1981
+ Transmission Control Protocol
+ Functional Specification
+
+
+
+ Initial Sequence Number Selection
+
+ The protocol places no restriction on a particular connection being
+ used over and over again. A connection is defined by a pair of
+ sockets. New instances of a connection will be referred to as
+ incarnations of the connection. The problem that arises from this is
+ -- "how does the TCP identify duplicate segments from previous
+ incarnations of the connection?" This problem becomes apparent if the
+ connection is being opened and closed in quick succession, or if the
+ connection breaks with loss of memory and is then reestablished.
+
+ To avoid confusion we must prevent segments from one incarnation of a
+ connection from being used while the same sequence numbers may still
+ be present in the network from an earlier incarnation. We want to
+ assure this, even if a TCP crashes and loses all knowledge of the
+ sequence numbers it has been using. When new connections are created,
+ an initial sequence number (ISN) generator is employed which selects a
+ new 32 bit ISN. The generator is bound to a (possibly fictitious) 32
+ bit clock whose low order bit is incremented roughly every 4
+ microseconds. Thus, the ISN cycles approximately every 4.55 hours.
+ Since we assume that segments will stay in the network no more than
+ the Maximum Segment Lifetime (MSL) and that the MSL is less than 4.55
+ hours we can reasonably assume that ISN's will be unique.
+
+ For each connection there is a send sequence number and a receive
+ sequence number. The initial send sequence number (ISS) is chosen by
+ the data sending TCP, and the initial receive sequence number (IRS) is
+ learned during the connection establishing procedure.
+
+ For a connection to be established or initialized, the two TCPs must
+ synchronize on each other's initial sequence numbers. This is done in
+ an exchange of connection establishing segments carrying a control bit
+ called "SYN" (for synchronize) and the initial sequence numbers. As a
+ shorthand, segments carrying the SYN bit are also called "SYNs".
+ Hence, the solution requires a suitable mechanism for picking an
+ initial sequence number and a slightly involved handshake to exchange
+ the ISN's.
+
+ The synchronization requires each side to send it's own initial
+ sequence number and to receive a confirmation of it in acknowledgment
+ from the other side. Each side must also receive the other side's
+ initial sequence number and send a confirming acknowledgment.
+
+ 1) A --> B SYN my sequence number is X
+ 2) A <-- B ACK your sequence number is X
+ 3) A <-- B SYN my sequence number is Y
+ 4) A --> B ACK your sequence number is Y
+
+
+
+ [Page 27]
+
+
+ September 1981
+Transmission Control Protocol
+Functional Specification
+
+
+
+ Because steps 2 and 3 can be combined in a single message this is
+ called the three way (or three message) handshake.
+
+ A three way handshake is necessary because sequence numbers are not
+ tied to a global clock in the network, and TCPs may have different
+ mechanisms for picking the ISN's. The receiver of the first SYN has
+ no way of knowing whether the segment was an old delayed one or not,
+ unless it remembers the last sequence number used on the connection
+ (which is not always possible), and so it must ask the sender to
+ verify this SYN. The three way handshake and the advantages of a
+ clock-driven scheme are discussed in [3].
+
+ Knowing When to Keep Quiet
+
+ To be sure that a TCP does not create a segment that carries a
+ sequence number which may be duplicated by an old segment remaining in
+ the network, the TCP must keep quiet for a maximum segment lifetime
+ (MSL) before assigning any sequence numbers upon starting up or
+ recovering from a crash in which memory of sequence numbers in use was
+ lost. For this specification the MSL is taken to be 2 minutes. This
+ is an engineering choice, and may be changed if experience indicates
+ it is desirable to do so. Note that if a TCP is reinitialized in some
+ sense, yet retains its memory of sequence numbers in use, then it need
+ not wait at all; it must only be sure to use sequence numbers larger
+ than those recently used.
+
+ The TCP Quiet Time Concept
+
+ This specification provides that hosts which "crash" without
+ retaining any knowledge of the last sequence numbers transmitted on
+ each active (i.e., not closed) connection shall delay emitting any
+ TCP segments for at least the agreed Maximum Segment Lifetime (MSL)
+ in the internet system of which the host is a part. In the
+ paragraphs below, an explanation for this specification is given.
+ TCP implementors may violate the "quiet time" restriction, but only
+ at the risk of causing some old data to be accepted as new or new
+ data rejected as old duplicated by some receivers in the internet
+ system.
+
+ TCPs consume sequence number space each time a segment is formed and
+ entered into the network output queue at a source host. The
+ duplicate detection and sequencing algorithm in the TCP protocol
+ relies on the unique binding of segment data to sequence space to
+ the extent that sequence numbers will not cycle through all 2**32
+ values before the segment data bound to those sequence numbers has
+ been delivered and acknowledged by the receiver and all duplicate
+ copies of the segments have "drained" from the internet. Without
+ such an assumption, two distinct TCP segments could conceivably be
+
+
+[Page 28]
+
+
+September 1981
+ Transmission Control Protocol
+ Functional Specification
+
+
+
+ assigned the same or overlapping sequence numbers, causing confusion
+ at the receiver as to which data is new and which is old. Remember
+ that each segment is bound to as many consecutive sequence numbers
+ as there are octets of data in the segment.
+
+ Under normal conditions, TCPs keep track of the next sequence number
+ to emit and the oldest awaiting acknowledgment so as to avoid
+ mistakenly using a sequence number over before its first use has
+ been acknowledged. This alone does not guarantee that old duplicate
+ data is drained from the net, so the sequence space has been made
+ very large to reduce the probability that a wandering duplicate will
+ cause trouble upon arrival. At 2 megabits/sec. it takes 4.5 hours
+ to use up 2**32 octets of sequence space. Since the maximum segment
+ lifetime in the net is not likely to exceed a few tens of seconds,
+ this is deemed ample protection for foreseeable nets, even if data
+ rates escalate to l0's of megabits/sec. At 100 megabits/sec, the
+ cycle time is 5.4 minutes which may be a little short, but still
+ within reason.
+
+ The basic duplicate detection and sequencing algorithm in TCP can be
+ defeated, however, if a source TCP does not have any memory of the
+ sequence numbers it last used on a given connection. For example, if
+ the TCP were to start all connections with sequence number 0, then
+ upon crashing and restarting, a TCP might re-form an earlier
+ connection (possibly after half-open connection resolution) and emit
+ packets with sequence numbers identical to or overlapping with
+ packets still in the network which were emitted on an earlier
+ incarnation of the same connection. In the absence of knowledge
+ about the sequence numbers used on a particular connection, the TCP
+ specification recommends that the source delay for MSL seconds
+ before emitting segments on the connection, to allow time for
+ segments from the earlier connection incarnation to drain from the
+ system.
+
+ Even hosts which can remember the time of day and used it to select
+ initial sequence number values are not immune from this problem
+ (i.e., even if time of day is used to select an initial sequence
+ number for each new connection incarnation).
+
+ Suppose, for example, that a connection is opened starting with
+ sequence number S. Suppose that this connection is not used much
+ and that eventually the initial sequence number function (ISN(t))
+ takes on a value equal to the sequence number, say S1, of the last
+ segment sent by this TCP on a particular connection. Now suppose,
+ at this instant, the host crashes, recovers, and establishes a new
+ incarnation of the connection. The initial sequence number chosen is
+ S1 = ISN(t) -- last used sequence number on old incarnation of
+ connection! If the recovery occurs quickly enough, any old
+
+
+ [Page 29]
+
+
+ September 1981
+Transmission Control Protocol
+Functional Specification
+
+
+
+ duplicates in the net bearing sequence numbers in the neighborhood
+ of S1 may arrive and be treated as new packets by the receiver of
+ the new incarnation of the connection.
+
+ The problem is that the recovering host may not know for how long it
+ crashed nor does it know whether there are still old duplicates in
+ the system from earlier connection incarnations.
+
+ One way to deal with this problem is to deliberately delay emitting
+ segments for one MSL after recovery from a crash- this is the "quite
+ time" specification. Hosts which prefer to avoid waiting are
+ willing to risk possible confusion of old and new packets at a given
+ destination may choose not to wait for the "quite time".
+ Implementors may provide TCP users with the ability to select on a
+ connection by connection basis whether to wait after a crash, or may
+ informally implement the "quite time" for all connections.
+ Obviously, even where a user selects to "wait," this is not
+ necessary after the host has been "up" for at least MSL seconds.
+
+ To summarize: every segment emitted occupies one or more sequence
+ numbers in the sequence space, the numbers occupied by a segment are
+ "busy" or "in use" until MSL seconds have passed, upon crashing a
+ block of space-time is occupied by the octets of the last emitted
+ segment, if a new connection is started too soon and uses any of the
+ sequence numbers in the space-time footprint of the last segment of
+ the previous connection incarnation, there is a potential sequence
+ number overlap area which could cause confusion at the receiver.
+
+3.4. Establishing a connection
+
+ The "three-way handshake" is the procedure used to establish a
+ connection. This procedure normally is initiated by one TCP and
+ responded to by another TCP. The procedure also works if two TCP
+ simultaneously initiate the procedure. When simultaneous attempt
+ occurs, each TCP receives a "SYN" segment which carries no
+ acknowledgment after it has sent a "SYN". Of course, the arrival of
+ an old duplicate "SYN" segment can potentially make it appear, to the
+ recipient, that a simultaneous connection initiation is in progress.
+ Proper use of "reset" segments can disambiguate these cases.
+
+ Several examples of connection initiation follow. Although these
+ examples do not show connection synchronization using data-carrying
+ segments, this is perfectly legitimate, so long as the receiving TCP
+ doesn't deliver the data to the user until it is clear the data is
+ valid (i.e., the data must be buffered at the receiver until the
+ connection reaches the ESTABLISHED state). The three-way handshake
+ reduces the possibility of false connections. It is the
+
+
+
+[Page 30]
+
+
+September 1981
+ Transmission Control Protocol
+ Functional Specification
+
+
+
+ implementation of a trade-off between memory and messages to provide
+ information for this checking.
+
+ The simplest three-way handshake is shown in figure 7 below. The
+ figures should be interpreted in the following way. Each line is
+ numbered for reference purposes. Right arrows (-->) indicate
+ departure of a TCP segment from TCP A to TCP B, or arrival of a
+ segment at B from A. Left arrows (<--), indicate the reverse.
+ Ellipsis (...) indicates a segment which is still in the network
+ (delayed). An "XXX" indicates a segment which is lost or rejected.
+ Comments appear in parentheses. TCP states represent the state AFTER
+ the departure or arrival of the segment (whose contents are shown in
+ the center of each line). Segment contents are shown in abbreviated
+ form, with sequence number, control flags, and ACK field. Other
+ fields such as window, addresses, lengths, and text have been left out
+ in the interest of clarity.
+
+
+
+ TCP A TCP B
+
+ 1. CLOSED LISTEN
+
+ 2. SYN-SENT --> <SEQ=100><CTL=SYN> --> SYN-RECEIVED
+
+ 3. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED
+
+ 4. ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK> --> ESTABLISHED
+
+ 5. ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK><DATA> --> ESTABLISHED
+
+ Basic 3-Way Handshake for Connection Synchronization
+
+ Figure 7.
+
+ In line 2 of figure 7, TCP A begins by sending a SYN segment
+ indicating that it will use sequence numbers starting with sequence
+ number 100. In line 3, TCP B sends a SYN and acknowledges the SYN it
+ received from TCP A. Note that the acknowledgment field indicates TCP
+ B is now expecting to hear sequence 101, acknowledging the SYN which
+ occupied sequence 100.
+
+ At line 4, TCP A responds with an empty segment containing an ACK for
+ TCP B's SYN; and in line 5, TCP A sends some data. Note that the
+ sequence number of the segment in line 5 is the same as in line 4
+ because the ACK does not occupy sequence number space (if it did, we
+ would wind up ACKing ACK's!).
+
+
+
+ [Page 31]
+
+
+ September 1981
+Transmission Control Protocol
+Functional Specification
+
+
+
+ Simultaneous initiation is only slightly more complex, as is shown in
+ figure 8. Each TCP cycles from CLOSED to SYN-SENT to SYN-RECEIVED to
+ ESTABLISHED.
+
+
+
+ TCP A TCP B
+
+ 1. CLOSED CLOSED
+
+ 2. SYN-SENT --> <SEQ=100><CTL=SYN> ...
+
+ 3. SYN-RECEIVED <-- <SEQ=300><CTL=SYN> <-- SYN-SENT
+
+ 4. ... <SEQ=100><CTL=SYN> --> SYN-RECEIVED
+
+ 5. SYN-RECEIVED --> <SEQ=100><ACK=301><CTL=SYN,ACK> ...
+
+ 6. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED
+
+ 7. ... <SEQ=101><ACK=301><CTL=ACK> --> ESTABLISHED
+
+ Simultaneous Connection Synchronization
+
+ Figure 8.
+
+ The principle reason for the three-way handshake is to prevent old
+ duplicate connection initiations from causing confusion. To deal with
+ this, a special control message, reset, has been devised. If the
+ receiving TCP is in a non-synchronized state (i.e., SYN-SENT,
+ SYN-RECEIVED), it returns to LISTEN on receiving an acceptable reset.
+ If the TCP is in one of the synchronized states (ESTABLISHED,
+ FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), it
+ aborts the connection and informs its user. We discuss this latter
+ case under "half-open" connections below.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 32]
+
+
+September 1981
+ Transmission Control Protocol
+ Functional Specification
+
+
+
+
+
+ TCP A TCP B
+
+ 1. CLOSED LISTEN
+
+ 2. SYN-SENT --> <SEQ=100><CTL=SYN> ...
+
+ 3. (duplicate) ... <SEQ=90><CTL=SYN> --> SYN-RECEIVED
+
+ 4. SYN-SENT <-- <SEQ=300><ACK=91><CTL=SYN,ACK> <-- SYN-RECEIVED
+
+ 5. SYN-SENT --> <SEQ=91><CTL=RST> --> LISTEN
+
+
+ 6. ... <SEQ=100><CTL=SYN> --> SYN-RECEIVED
+
+ 7. SYN-SENT <-- <SEQ=400><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED
+
+ 8. ESTABLISHED --> <SEQ=101><ACK=401><CTL=ACK> --> ESTABLISHED
+
+ Recovery from Old Duplicate SYN
+
+ Figure 9.
+
+ As a simple example of recovery from old duplicates, consider
+ figure 9. At line 3, an old duplicate SYN arrives at TCP B. TCP B
+ cannot tell that this is an old duplicate, so it responds normally
+ (line 4). TCP A detects that the ACK field is incorrect and returns a
+ RST (reset) with its SEQ field selected to make the segment
+ believable. TCP B, on receiving the RST, returns to the LISTEN state.
+ When the original SYN (pun intended) finally arrives at line 6, the
+ synchronization proceeds normally. If the SYN at line 6 had arrived
+ before the RST, a more complex exchange might have occurred with RST's
+ sent in both directions.
+
+ Half-Open Connections and Other Anomalies
+
+ An established connection is said to be "half-open" if one of the
+ TCPs has closed or aborted the connection at its end without the
+ knowledge of the other, or if the two ends of the connection have
+ become desynchronized owing to a crash that resulted in loss of
+ memory. Such connections will automatically become reset if an
+ attempt is made to send data in either direction. However, half-open
+ connections are expected to be unusual, and the recovery procedure is
+ mildly involved.
+
+ If at site A the connection no longer exists, then an attempt by the
+
+
+ [Page 33]
+
+
+ September 1981
+Transmission Control Protocol
+Functional Specification
+
+
+
+ user at site B to send any data on it will result in the site B TCP
+ receiving a reset control message. Such a message indicates to the
+ site B TCP that something is wrong, and it is expected to abort the
+ connection.
+
+ Assume that two user processes A and B are communicating with one
+ another when a crash occurs causing loss of memory to A's TCP.
+ Depending on the operating system supporting A's TCP, it is likely
+ that some error recovery mechanism exists. When the TCP is up again,
+ A is likely to start again from the beginning or from a recovery
+ point. As a result, A will probably try to OPEN the connection again
+ or try to SEND on the connection it believes open. In the latter
+ case, it receives the error message "connection not open" from the
+ local (A's) TCP. In an attempt to establish the connection, A's TCP
+ will send a segment containing SYN. This scenario leads to the
+ example shown in figure 10. After TCP A crashes, the user attempts to
+ re-open the connection. TCP B, in the meantime, thinks the connection
+ is open.
+
+
+
+ TCP A TCP B
+
+ 1. (CRASH) (send 300,receive 100)
+
+ 2. CLOSED ESTABLISHED
+
+ 3. SYN-SENT --> <SEQ=400><CTL=SYN> --> (??)
+
+ 4. (!!) <-- <SEQ=300><ACK=100><CTL=ACK> <-- ESTABLISHED
+
+ 5. SYN-SENT --> <SEQ=100><CTL=RST> --> (Abort!!)
+
+ 6. SYN-SENT CLOSED
+
+ 7. SYN-SENT --> <SEQ=400><CTL=SYN> -->
+
+ Half-Open Connection Discovery
+
+ Figure 10.
+
+ When the SYN arrives at line 3, TCP B, being in a synchronized state,
+ and the incoming segment outside the window, responds with an
+ acknowledgment indicating what sequence it next expects to hear (ACK
+ 100). TCP A sees that this segment does not acknowledge anything it
+ sent and, being unsynchronized, sends a reset (RST) because it has
+ detected a half-open connection. TCP B aborts at line 5. TCP A will
+
+
+
+[Page 34]
+
+
+September 1981
+ Transmission Control Protocol
+ Functional Specification
+
+
+
+ continue to try to establish the connection; the problem is now
+ reduced to the basic 3-way handshake of figure 7.
+
+ An interesting alternative case occurs when TCP A crashes and TCP B
+ tries to send data on what it thinks is a synchronized connection.
+ This is illustrated in figure 11. In this case, the data arriving at
+ TCP A from TCP B (line 2) is unacceptable because no such connection
+ exists, so TCP A sends a RST. The RST is acceptable so TCP B
+ processes it and aborts the connection.
+
+
+
+ TCP A TCP B
+
+ 1. (CRASH) (send 300,receive 100)
+
+ 2. (??) <-- <SEQ=300><ACK=100><DATA=10><CTL=ACK> <-- ESTABLISHED
+
+ 3. --> <SEQ=100><CTL=RST> --> (ABORT!!)
+
+ Active Side Causes Half-Open Connection Discovery
+
+ Figure 11.
+
+ In figure 12, we find the two TCPs A and B with passive connections
+ waiting for SYN. An old duplicate arriving at TCP B (line 2) stirs B
+ into action. A SYN-ACK is returned (line 3) and causes TCP A to
+ generate a RST (the ACK in line 3 is not acceptable). TCP B accepts
+ the reset and returns to its passive LISTEN state.
+
+
+
+ TCP A TCP B
+
+ 1. LISTEN LISTEN
+
+ 2. ... <SEQ=Z><CTL=SYN> --> SYN-RECEIVED
+
+ 3. (??) <-- <SEQ=X><ACK=Z+1><CTL=SYN,ACK> <-- SYN-RECEIVED
+
+ 4. --> <SEQ=Z+1><CTL=RST> --> (return to LISTEN!)
+
+ 5. LISTEN LISTEN
+
+ Old Duplicate SYN Initiates a Reset on two Passive Sockets
+
+ Figure 12.
+
+
+
+ [Page 35]
+
+
+ September 1981
+Transmission Control Protocol
+Functional Specification
+
+
+
+ A variety of other cases are possible, all of which are accounted for
+ by the following rules for RST generation and processing.
+
+ Reset Generation
+
+ As a general rule, reset (RST) must be sent whenever a segment arrives
+ which apparently is not intended for the current connection. A reset
+ must not be sent if it is not clear that this is the case.
+
+ There are three groups of states:
+
+ 1. If the connection does not exist (CLOSED) then a reset is sent
+ in response to any incoming segment except another reset. In
+ particular, SYNs addressed to a non-existent connection are rejected
+ by this means.
+
+ If the incoming segment has an ACK field, the reset takes its
+ sequence number from the ACK field of the segment, otherwise the
+ reset has sequence number zero and the ACK field is set to the sum
+ of the sequence number and segment length of the incoming segment.
+ The connection remains in the CLOSED state.
+
+ 2. If the connection is in any non-synchronized state (LISTEN,
+ SYN-SENT, SYN-RECEIVED), and the incoming segment acknowledges
+ something not yet sent (the segment carries an unacceptable ACK), or
+ if an incoming segment has a security level or compartment which
+ does not exactly match the level and compartment requested for the
+ connection, a reset is sent.
+
+ If our SYN has not been acknowledged and the precedence level of the
+ incoming segment is higher than the precedence level requested then
+ either raise the local precedence level (if allowed by the user and
+ the system) or send a reset; or if the precedence level of the
+ incoming segment is lower than the precedence level requested then
+ continue as if the precedence matched exactly (if the remote TCP
+ cannot raise the precedence level to match ours this will be
+ detected in the next segment it sends, and the connection will be
+ terminated then). If our SYN has been acknowledged (perhaps in this
+ incoming segment) the precedence level of the incoming segment must
+ match the local precedence level exactly, if it does not a reset
+ must be sent.
+
+ If the incoming segment has an ACK field, the reset takes its
+ sequence number from the ACK field of the segment, otherwise the
+ reset has sequence number zero and the ACK field is set to the sum
+ of the sequence number and segment length of the incoming segment.
+ The connection remains in the same state.
+
+
+
+[Page 36]
+
+
+September 1981
+ Transmission Control Protocol
+ Functional Specification
+
+
+
+ 3. If the connection is in a synchronized state (ESTABLISHED,
+ FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT),
+ any unacceptable segment (out of window sequence number or
+ unacceptible acknowledgment number) must elicit only an empty
+ acknowledgment segment containing the current send-sequence number
+ and an acknowledgment indicating the next sequence number expected
+ to be received, and the connection remains in the same state.
+
+ If an incoming segment has a security level, or compartment, or
+ precedence which does not exactly match the level, and compartment,
+ and precedence requested for the connection,a reset is sent and
+ connection goes to the CLOSED state. The reset takes its sequence
+ number from the ACK field of the incoming segment.
+
+ Reset Processing
+
+ In all states except SYN-SENT, all reset (RST) segments are validated
+ by checking their SEQ-fields. A reset is valid if its sequence number
+ is in the window. In the SYN-SENT state (a RST received in response
+ to an initial SYN), the RST is acceptable if the ACK field
+ acknowledges the SYN.
+
+ The receiver of a RST first validates it, then changes state. If the
+ receiver was in the LISTEN state, it ignores it. If the receiver was
+ in SYN-RECEIVED state and had previously been in the LISTEN state,
+ then the receiver returns to the LISTEN state, otherwise the receiver
+ aborts the connection and goes to the CLOSED state. If the receiver
+ was in any other state, it aborts the connection and advises the user
+ and goes to the CLOSED state.
+
+3.5. Closing a Connection
+
+ CLOSE is an operation meaning "I have no more data to send." The
+ notion of closing a full-duplex connection is subject to ambiguous
+ interpretation, of course, since it may not be obvious how to treat
+ the receiving side of the connection. We have chosen to treat CLOSE
+ in a simplex fashion. The user who CLOSEs may continue to RECEIVE
+ until he is told that the other side has CLOSED also. Thus, a program
+ could initiate several SENDs followed by a CLOSE, and then continue to
+ RECEIVE until signaled that a RECEIVE failed because the other side
+ has CLOSED. We assume that the TCP will signal a user, even if no
+ RECEIVEs are outstanding, that the other side has closed, so the user
+ can terminate his side gracefully. A TCP will reliably deliver all
+ buffers SENT before the connection was CLOSED so a user who expects no
+ data in return need only wait to hear the connection was CLOSED
+ successfully to know that all his data was received at the destination
+ TCP. Users must keep reading connections they close for sending until
+ the TCP says no more data.
+
+
+ [Page 37]
+
+
+ September 1981
+Transmission Control Protocol
+Functional Specification
+
+
+
+ There are essentially three cases:
+
+ 1) The user initiates by telling the TCP to CLOSE the connection
+
+ 2) The remote TCP initiates by sending a FIN control signal
+
+ 3) Both users CLOSE simultaneously
+
+ Case 1: Local user initiates the close
+
+ In this case, a FIN segment can be constructed and placed on the
+ outgoing segment queue. No further SENDs from the user will be
+ accepted by the TCP, and it enters the FIN-WAIT-1 state. RECEIVEs
+ are allowed in this state. All segments preceding and including FIN
+ will be retransmitted until acknowledged. When the other TCP has
+ both acknowledged the FIN and sent a FIN of its own, the first TCP
+ can ACK this FIN. Note that a TCP receiving a FIN will ACK but not
+ send its own FIN until its user has CLOSED the connection also.
+
+ Case 2: TCP receives a FIN from the network
+
+ If an unsolicited FIN arrives from the network, the receiving TCP
+ can ACK it and tell the user that the connection is closing. The
+ user will respond with a CLOSE, upon which the TCP can send a FIN to
+ the other TCP after sending any remaining data. The TCP then waits
+ until its own FIN is acknowledged whereupon it deletes the
+ connection. If an ACK is not forthcoming, after the user timeout
+ the connection is aborted and the user is told.
+
+ Case 3: both users close simultaneously
+
+ A simultaneous CLOSE by users at both ends of a connection causes
+ FIN segments to be exchanged. When all segments preceding the FINs
+ have been processed and acknowledged, each TCP can ACK the FIN it
+ has received. Both will, upon receiving these ACKs, delete the
+ connection.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 38]
+
+
+September 1981
+ Transmission Control Protocol
+ Functional Specification
+
+
+
+
+
+ TCP A TCP B
+
+ 1. ESTABLISHED ESTABLISHED
+
+ 2. (Close)
+ FIN-WAIT-1 --> <SEQ=100><ACK=300><CTL=FIN,ACK> --> CLOSE-WAIT
+
+ 3. FIN-WAIT-2 <-- <SEQ=300><ACK=101><CTL=ACK> <-- CLOSE-WAIT
+
+ 4. (Close)
+ TIME-WAIT <-- <SEQ=300><ACK=101><CTL=FIN,ACK> <-- LAST-ACK
+
+ 5. TIME-WAIT --> <SEQ=101><ACK=301><CTL=ACK> --> CLOSED
+
+ 6. (2 MSL)
+ CLOSED
+
+ Normal Close Sequence
+
+ Figure 13.
+
+
+
+ TCP A TCP B
+
+ 1. ESTABLISHED ESTABLISHED
+
+ 2. (Close) (Close)
+ FIN-WAIT-1 --> <SEQ=100><ACK=300><CTL=FIN,ACK> ... FIN-WAIT-1
+ <-- <SEQ=300><ACK=100><CTL=FIN,ACK> <--
+ ... <SEQ=100><ACK=300><CTL=FIN,ACK> -->
+
+ 3. CLOSING --> <SEQ=101><ACK=301><CTL=ACK> ... CLOSING
+ <-- <SEQ=301><ACK=101><CTL=ACK> <--
+ ... <SEQ=101><ACK=301><CTL=ACK> -->
+
+ 4. TIME-WAIT TIME-WAIT
+ (2 MSL) (2 MSL)
+ CLOSED CLOSED
+
+ Simultaneous Close Sequence
+
+ Figure 14.
+
+
+
+
+
+ [Page 39]
+
+
+ September 1981
+Transmission Control Protocol
+Functional Specification
+
+
+
+3.6. Precedence and Security
+
+ The intent is that connection be allowed only between ports operating
+ with exactly the same security and compartment values and at the
+ higher of the precedence level requested by the two ports.
+
+ The precedence and security parameters used in TCP are exactly those
+ defined in the Internet Protocol (IP) [2]. Throughout this TCP
+ specification the term "security/compartment" is intended to indicate
+ the security parameters used in IP including security, compartment,
+ user group, and handling restriction.
+
+ A connection attempt with mismatched security/compartment values or a
+ lower precedence value must be rejected by sending a reset. Rejecting
+ a connection due to too low a precedence only occurs after an
+ acknowledgment of the SYN has been received.
+
+ Note that TCP modules which operate only at the default value of
+ precedence will still have to check the precedence of incoming
+ segments and possibly raise the precedence level they use on the
+ connection.
+
+ The security paramaters may be used even in a non-secure environment
+ (the values would indicate unclassified data), thus hosts in
+ non-secure environments must be prepared to receive the security
+ parameters, though they need not send them.
+
+3.7. Data Communication
+
+ Once the connection is established data is communicated by the
+ exchange of segments. Because segments may be lost due to errors
+ (checksum test failure), or network congestion, TCP uses
+ retransmission (after a timeout) to ensure delivery of every segment.
+ Duplicate segments may arrive due to network or TCP retransmission.
+ As discussed in the section on sequence numbers the TCP performs
+ certain tests on the sequence and acknowledgment numbers in the
+ segments to verify their acceptability.
+
+ The sender of data keeps track of the next sequence number to use in
+ the variable SND.NXT. The receiver of data keeps track of the next
+ sequence number to expect in the variable RCV.NXT. The sender of data
+ keeps track of the oldest unacknowledged sequence number in the
+ variable SND.UNA. If the data flow is momentarily idle and all data
+ sent has been acknowledged then the three variables will be equal.
+
+ When the sender creates a segment and transmits it the sender advances
+ SND.NXT. When the receiver accepts a segment it advances RCV.NXT and
+ sends an acknowledgment. When the data sender receives an
+
+
+[Page 40]
+
+
+September 1981
+ Transmission Control Protocol
+ Functional Specification
+
+
+
+ acknowledgment it advances SND.UNA. The extent to which the values of
+ these variables differ is a measure of the delay in the communication.
+ The amount by which the variables are advanced is the length of the
+ data in the segment. Note that once in the ESTABLISHED state all
+ segments must carry current acknowledgment information.
+
+ The CLOSE user call implies a push function, as does the FIN control
+ flag in an incoming segment.
+
+ Retransmission Timeout
+
+ Because of the variability of the networks that compose an
+ internetwork system and the wide range of uses of TCP connections the
+ retransmission timeout must be dynamically determined. One procedure
+ for determining a retransmission time out is given here as an
+ illustration.
+
+ An Example Retransmission Timeout Procedure
+
+ Measure the elapsed time between sending a data octet with a
+ particular sequence number and receiving an acknowledgment that
+ covers that sequence number (segments sent do not have to match
+ segments received). This measured elapsed time is the Round Trip
+ Time (RTT). Next compute a Smoothed Round Trip Time (SRTT) as:
+
+ SRTT = ( ALPHA * SRTT ) + ((1-ALPHA) * RTT)
+
+ and based on this, compute the retransmission timeout (RTO) as:
+
+ RTO = min[UBOUND,max[LBOUND,(BETA*SRTT)]]
+
+ where UBOUND is an upper bound on the timeout (e.g., 1 minute),
+ LBOUND is a lower bound on the timeout (e.g., 1 second), ALPHA is
+ a smoothing factor (e.g., .8 to .9), and BETA is a delay variance
+ factor (e.g., 1.3 to 2.0).
+
+ The Communication of Urgent Information
+
+ The objective of the TCP urgent mechanism is to allow the sending user
+ to stimulate the receiving user to accept some urgent data and to
+ permit the receiving TCP to indicate to the receiving user when all
+ the currently known urgent data has been received by the user.
+
+ This mechanism permits a point in the data stream to be designated as
+ the end of urgent information. Whenever this point is in advance of
+ the receive sequence number (RCV.NXT) at the receiving TCP, that TCP
+ must tell the user to go into "urgent mode"; when the receive sequence
+ number catches up to the urgent pointer, the TCP must tell user to go
+
+
+ [Page 41]
+
+
+ September 1981
+Transmission Control Protocol
+Functional Specification
+
+
+
+ into "normal mode". If the urgent pointer is updated while the user
+ is in "urgent mode", the update will be invisible to the user.
+
+ The method employs a urgent field which is carried in all segments
+ transmitted. The URG control flag indicates that the urgent field is
+ meaningful and must be added to the segment sequence number to yield
+ the urgent pointer. The absence of this flag indicates that there is
+ no urgent data outstanding.
+
+ To send an urgent indication the user must also send at least one data
+ octet. If the sending user also indicates a push, timely delivery of
+ the urgent information to the destination process is enhanced.
+
+ Managing the Window
+
+ The window sent in each segment indicates the range of sequence
+ numbers the sender of the window (the data receiver) is currently
+ prepared to accept. There is an assumption that this is related to
+ the currently available data buffer space available for this
+ connection.
+
+ Indicating a large window encourages transmissions. If more data
+ arrives than can be accepted, it will be discarded. This will result
+ in excessive retransmissions, adding unnecessarily to the load on the
+ network and the TCPs. Indicating a small window may restrict the
+ transmission of data to the point of introducing a round trip delay
+ between each new segment transmitted.
+
+ The mechanisms provided allow a TCP to advertise a large window and to
+ subsequently advertise a much smaller window without having accepted
+ that much data. This, so called "shrinking the window," is strongly
+ discouraged. The robustness principle dictates that TCPs will not
+ shrink the window themselves, but will be prepared for such behavior
+ on the part of other TCPs.
+
+ The sending TCP must be prepared to accept from the user and send at
+ least one octet of new data even if the send window is zero. The
+ sending TCP must regularly retransmit to the receiving TCP even when
+ the window is zero. Two minutes is recommended for the retransmission
+ interval when the window is zero. This retransmission is essential to
+ guarantee that when either TCP has a zero window the re-opening of the
+ window will be reliably reported to the other.
+
+ When the receiving TCP has a zero window and a segment arrives it must
+ still send an acknowledgment showing its next expected sequence number
+ and current window (zero).
+
+ The sending TCP packages the data to be transmitted into segments
+
+
+[Page 42]
+
+
+September 1981
+ Transmission Control Protocol
+ Functional Specification
+
+
+
+ which fit the current window, and may repackage segments on the
+ retransmission queue. Such repackaging is not required, but may be
+ helpful.
+
+ In a connection with a one-way data flow, the window information will
+ be carried in acknowledgment segments that all have the same sequence
+ number so there will be no way to reorder them if they arrive out of
+ order. This is not a serious problem, but it will allow the window
+ information to be on occasion temporarily based on old reports from
+ the data receiver. A refinement to avoid this problem is to act on
+ the window information from segments that carry the highest
+ acknowledgment number (that is segments with acknowledgment number
+ equal or greater than the highest previously received).
+
+ The window management procedure has significant influence on the
+ communication performance. The following comments are suggestions to
+ implementers.
+
+ Window Management Suggestions
+
+ Allocating a very small window causes data to be transmitted in
+ many small segments when better performance is achieved using
+ fewer large segments.
+
+ One suggestion for avoiding small windows is for the receiver to
+ defer updating a window until the additional allocation is at
+ least X percent of the maximum allocation possible for the
+ connection (where X might be 20 to 40).
+
+ Another suggestion is for the sender to avoid sending small
+ segments by waiting until the window is large enough before
+ sending data. If the the user signals a push function then the
+ data must be sent even if it is a small segment.
+
+ Note that the acknowledgments should not be delayed or unnecessary
+ retransmissions will result. One strategy would be to send an
+ acknowledgment when a small segment arrives (with out updating the
+ window information), and then to send another acknowledgment with
+ new window information when the window is larger.
+
+ The segment sent to probe a zero window may also begin a break up
+ of transmitted data into smaller and smaller segments. If a
+ segment containing a single data octet sent to probe a zero window
+ is accepted, it consumes one octet of the window now available.
+ If the sending TCP simply sends as much as it can whenever the
+ window is non zero, the transmitted data will be broken into
+ alternating big and small segments. As time goes on, occasional
+ pauses in the receiver making window allocation available will
+
+
+ [Page 43]
+
+
+ September 1981
+Transmission Control Protocol
+Functional Specification
+
+
+
+ result in breaking the big segments into a small and not quite so
+ big pair. And after a while the data transmission will be in
+ mostly small segments.
+
+ The suggestion here is that the TCP implementations need to
+ actively attempt to combine small window allocations into larger
+ windows, since the mechanisms for managing the window tend to lead
+ to many small windows in the simplest minded implementations.
+
+3.8. Interfaces
+
+ There are of course two interfaces of concern: the user/TCP interface
+ and the TCP/lower-level interface. We have a fairly elaborate model
+ of the user/TCP interface, but the interface to the lower level
+ protocol module is left unspecified here, since it will be specified
+ in detail by the specification of the lowel level protocol. For the
+ case that the lower level is IP we note some of the parameter values
+ that TCPs might use.
+
+ User/TCP Interface
+
+ The following functional description of user commands to the TCP is,
+ at best, fictional, since every operating system will have different
+ facilities. Consequently, we must warn readers that different TCP
+ implementations may have different user interfaces. However, all
+ TCPs must provide a certain minimum set of services to guarantee
+ that all TCP implementations can support the same protocol
+ hierarchy. This section specifies the functional interfaces
+ required of all TCP implementations.
+
+ TCP User Commands
+
+ The following sections functionally characterize a USER/TCP
+ interface. The notation used is similar to most procedure or
+ function calls in high level languages, but this usage is not
+ meant to rule out trap type service calls (e.g., SVCs, UUOs,
+ EMTs).
+
+ The user commands described below specify the basic functions the
+ TCP must perform to support interprocess communication.
+ Individual implementations must define their own exact format, and
+ may provide combinations or subsets of the basic functions in
+ single calls. In particular, some implementations may wish to
+ automatically OPEN a connection on the first SEND or RECEIVE
+ issued by the user for a given connection.
+
+
+
+
+
+[Page 44]
+
+
+September 1981
+ Transmission Control Protocol
+ Functional Specification
+
+
+
+ In providing interprocess communication facilities, the TCP must
+ not only accept commands, but must also return information to the
+ processes it serves. The latter consists of:
+
+ (a) general information about a connection (e.g., interrupts,
+ remote close, binding of unspecified foreign socket).
+
+ (b) replies to specific user commands indicating success or
+ various types of failure.
+
+ Open
+
+ Format: OPEN (local port, foreign socket, active/passive
+ [, timeout] [, precedence] [, security/compartment] [, options])
+ -> local connection name
+
+ We assume that the local TCP is aware of the identity of the
+ processes it serves and will check the authority of the process
+ to use the connection specified. Depending upon the
+ implementation of the TCP, the local network and TCP identifiers
+ for the source address will either be supplied by the TCP or the
+ lower level protocol (e.g., IP). These considerations are the
+ result of concern about security, to the extent that no TCP be
+ able to masquerade as another one, and so on. Similarly, no
+ process can masquerade as another without the collusion of the
+ TCP.
+
+ If the active/passive flag is set to passive, then this is a
+ call to LISTEN for an incoming connection. A passive open may
+ have either a fully specified foreign socket to wait for a
+ particular connection or an unspecified foreign socket to wait
+ for any call. A fully specified passive call can be made active
+ by the subsequent execution of a SEND.
+
+ A transmission control block (TCB) is created and partially
+ filled in with data from the OPEN command parameters.
+
+ On an active OPEN command, the TCP will begin the procedure to
+ synchronize (i.e., establish) the connection at once.
+
+ The timeout, if present, permits the caller to set up a timeout
+ for all data submitted to TCP. If data is not successfully
+ delivered to the destination within the timeout period, the TCP
+ will abort the connection. The present global default is five
+ minutes.
+
+ The TCP or some component of the operating system will verify
+ the users authority to open a connection with the specified
+
+
+ [Page 45]
+
+
+ September 1981
+Transmission Control Protocol
+Functional Specification
+
+
+
+ precedence or security/compartment. The absence of precedence
+ or security/compartment specification in the OPEN call indicates
+ the default values must be used.
+
+ TCP will accept incoming requests as matching only if the
+ security/compartment information is exactly the same and only if
+ the precedence is equal to or higher than the precedence
+ requested in the OPEN call.
+
+ The precedence for the connection is the higher of the values
+ requested in the OPEN call and received from the incoming
+ request, and fixed at that value for the life of the
+ connection.Implementers may want to give the user control of
+ this precedence negotiation. For example, the user might be
+ allowed to specify that the precedence must be exactly matched,
+ or that any attempt to raise the precedence be confirmed by the
+ user.
+
+ A local connection name will be returned to the user by the TCP.
+ The local connection name can then be used as a short hand term
+ for the connection defined by the <local socket, foreign socket>
+ pair.
+
+ Send
+
+ Format: SEND (local connection name, buffer address, byte
+ count, PUSH flag, URGENT flag [,timeout])
+
+ This call causes the data contained in the indicated user buffer
+ to be sent on the indicated connection. If the connection has
+ not been opened, the SEND is considered an error. Some
+ implementations may allow users to SEND first; in which case, an
+ automatic OPEN would be done. If the calling process is not
+ authorized to use this connection, an error is returned.
+
+ If the PUSH flag is set, the data must be transmitted promptly
+ to the receiver, and the PUSH bit will be set in the last TCP
+ segment created from the buffer. If the PUSH flag is not set,
+ the data may be combined with data from subsequent SENDs for
+ transmission efficiency.
+
+ If the URGENT flag is set, segments sent to the destination TCP
+ will have the urgent pointer set. The receiving TCP will signal
+ the urgent condition to the receiving process if the urgent
+ pointer indicates that data preceding the urgent pointer has not
+ been consumed by the receiving process. The purpose of urgent
+ is to stimulate the receiver to process the urgent data and to
+ indicate to the receiver when all the currently known urgent
+
+
+[Page 46]
+
+
+September 1981
+ Transmission Control Protocol
+ Functional Specification
+
+
+
+ data has been received. The number of times the sending user's
+ TCP signals urgent will not necessarily be equal to the number
+ of times the receiving user will be notified of the presence of
+ urgent data.
+
+ If no foreign socket was specified in the OPEN, but the
+ connection is established (e.g., because a LISTENing connection
+ has become specific due to a foreign segment arriving for the
+ local socket), then the designated buffer is sent to the implied
+ foreign socket. Users who make use of OPEN with an unspecified
+ foreign socket can make use of SEND without ever explicitly
+ knowing the foreign socket address.
+
+ However, if a SEND is attempted before the foreign socket
+ becomes specified, an error will be returned. Users can use the
+ STATUS call to determine the status of the connection. In some
+ implementations the TCP may notify the user when an unspecified
+ socket is bound.
+
+ If a timeout is specified, the current user timeout for this
+ connection is changed to the new one.
+
+ In the simplest implementation, SEND would not return control to
+ the sending process until either the transmission was complete
+ or the timeout had been exceeded. However, this simple method
+ is both subject to deadlocks (for example, both sides of the
+ connection might try to do SENDs before doing any RECEIVEs) and
+ offers poor performance, so it is not recommended. A more
+ sophisticated implementation would return immediately to allow
+ the process to run concurrently with network I/O, and,
+ furthermore, to allow multiple SENDs to be in progress.
+ Multiple SENDs are served in first come, first served order, so
+ the TCP will queue those it cannot service immediately.
+
+ We have implicitly assumed an asynchronous user interface in
+ which a SEND later elicits some kind of SIGNAL or
+ pseudo-interrupt from the serving TCP. An alternative is to
+ return a response immediately. For instance, SENDs might return
+ immediate local acknowledgment, even if the segment sent had not
+ been acknowledged by the distant TCP. We could optimistically
+ assume eventual success. If we are wrong, the connection will
+ close anyway due to the timeout. In implementations of this
+ kind (synchronous), there will still be some asynchronous
+ signals, but these will deal with the connection itself, and not
+ with specific segments or buffers.
+
+ In order for the process to distinguish among error or success
+ indications for different SENDs, it might be appropriate for the
+
+
+ [Page 47]
+
+
+ September 1981
+Transmission Control Protocol
+Functional Specification
+
+
+
+ buffer address to be returned along with the coded response to
+ the SEND request. TCP-to-user signals are discussed below,
+ indicating the information which should be returned to the
+ calling process.
+
+ Receive
+
+ Format: RECEIVE (local connection name, buffer address, byte
+ count) -> byte count, urgent flag, push flag
+
+ This command allocates a receiving buffer associated with the
+ specified connection. If no OPEN precedes this command or the
+ calling process is not authorized to use this connection, an
+ error is returned.
+
+ In the simplest implementation, control would not return to the
+ calling program until either the buffer was filled, or some
+ error occurred, but this scheme is highly subject to deadlocks.
+ A more sophisticated implementation would permit several
+ RECEIVEs to be outstanding at once. These would be filled as
+ segments arrive. This strategy permits increased throughput at
+ the cost of a more elaborate scheme (possibly asynchronous) to
+ notify the calling program that a PUSH has been seen or a buffer
+ filled.
+
+ If enough data arrive to fill the buffer before a PUSH is seen,
+ the PUSH flag will not be set in the response to the RECEIVE.
+ The buffer will be filled with as much data as it can hold. If
+ a PUSH is seen before the buffer is filled the buffer will be
+ returned partially filled and PUSH indicated.
+
+ If there is urgent data the user will have been informed as soon
+ as it arrived via a TCP-to-user signal. The receiving user
+ should thus be in "urgent mode". If the URGENT flag is on,
+ additional urgent data remains. If the URGENT flag is off, this
+ call to RECEIVE has returned all the urgent data, and the user
+ may now leave "urgent mode". Note that data following the
+ urgent pointer (non-urgent data) cannot be delivered to the user
+ in the same buffer with preceeding urgent data unless the
+ boundary is clearly marked for the user.
+
+ To distinguish among several outstanding RECEIVEs and to take
+ care of the case that a buffer is not completely filled, the
+ return code is accompanied by both a buffer pointer and a byte
+ count indicating the actual length of the data received.
+
+ Alternative implementations of RECEIVE might have the TCP
+
+
+
+[Page 48]
+
+
+September 1981
+ Transmission Control Protocol
+ Functional Specification
+
+
+
+ allocate buffer storage, or the TCP might share a ring buffer
+ with the user.
+
+ Close
+
+ Format: CLOSE (local connection name)
+
+ This command causes the connection specified to be closed. If
+ the connection is not open or the calling process is not
+ authorized to use this connection, an error is returned.
+ Closing connections is intended to be a graceful operation in
+ the sense that outstanding SENDs will be transmitted (and
+ retransmitted), as flow control permits, until all have been
+ serviced. Thus, it should be acceptable to make several SEND
+ calls, followed by a CLOSE, and expect all the data to be sent
+ to the destination. It should also be clear that users should
+ continue to RECEIVE on CLOSING connections, since the other side
+ may be trying to transmit the last of its data. Thus, CLOSE
+ means "I have no more to send" but does not mean "I will not
+ receive any more." It may happen (if the user level protocol is
+ not well thought out) that the closing side is unable to get rid
+ of all its data before timing out. In this event, CLOSE turns
+ into ABORT, and the closing TCP gives up.
+
+ The user may CLOSE the connection at any time on his own
+ initiative, or in response to various prompts from the TCP
+ (e.g., remote close executed, transmission timeout exceeded,
+ destination inaccessible).
+
+ Because closing a connection requires communication with the
+ foreign TCP, connections may remain in the closing state for a
+ short time. Attempts to reopen the connection before the TCP
+ replies to the CLOSE command will result in error responses.
+
+ Close also implies push function.
+
+ Status
+
+ Format: STATUS (local connection name) -> status data
+
+ This is an implementation dependent user command and could be
+ excluded without adverse effect. Information returned would
+ typically come from the TCB associated with the connection.
+
+ This command returns a data block containing the following
+ information:
+
+ local socket,
+
+
+ [Page 49]
+
+
+ September 1981
+Transmission Control Protocol
+Functional Specification
+
+
+
+ foreign socket,
+ local connection name,
+ receive window,
+ send window,
+ connection state,
+ number of buffers awaiting acknowledgment,
+ number of buffers pending receipt,
+ urgent state,
+ precedence,
+ security/compartment,
+ and transmission timeout.
+
+ Depending on the state of the connection, or on the
+ implementation itself, some of this information may not be
+ available or meaningful. If the calling process is not
+ authorized to use this connection, an error is returned. This
+ prevents unauthorized processes from gaining information about a
+ connection.
+
+ Abort
+
+ Format: ABORT (local connection name)
+
+ This command causes all pending SENDs and RECEIVES to be
+ aborted, the TCB to be removed, and a special RESET message to
+ be sent to the TCP on the other side of the connection.
+ Depending on the implementation, users may receive abort
+ indications for each outstanding SEND or RECEIVE, or may simply
+ receive an ABORT-acknowledgment.
+
+ TCP-to-User Messages
+
+ It is assumed that the operating system environment provides a
+ means for the TCP to asynchronously signal the user program. When
+ the TCP does signal a user program, certain information is passed
+ to the user. Often in the specification the information will be
+ an error message. In other cases there will be information
+ relating to the completion of processing a SEND or RECEIVE or
+ other user call.
+
+ The following information is provided:
+
+ Local Connection Name Always
+ Response String Always
+ Buffer Address Send & Receive
+ Byte count (counts bytes received) Receive
+ Push flag Receive
+ Urgent flag Receive
+
+
+[Page 50]
+
+
+September 1981
+ Transmission Control Protocol
+ Functional Specification
+
+
+
+ TCP/Lower-Level Interface
+
+ The TCP calls on a lower level protocol module to actually send and
+ receive information over a network. One case is that of the ARPA
+ internetwork system where the lower level module is the Internet
+ Protocol (IP) [2].
+
+ If the lower level protocol is IP it provides arguments for a type
+ of service and for a time to live. TCP uses the following settings
+ for these parameters:
+
+ Type of Service = Precedence: routine, Delay: normal, Throughput:
+ normal, Reliability: normal; or 00000000.
+
+ Time to Live = one minute, or 00111100.
+
+ Note that the assumed maximum segment lifetime is two minutes.
+ Here we explicitly ask that a segment be destroyed if it cannot
+ be delivered by the internet system within one minute.
+
+ If the lower level is IP (or other protocol that provides this
+ feature) and source routing is used, the interface must allow the
+ route information to be communicated. This is especially important
+ so that the source and destination addresses used in the TCP
+ checksum be the originating source and ultimate destination. It is
+ also important to preserve the return route to answer connection
+ requests.
+
+ Any lower level protocol will have to provide the source address,
+ destination address, and protocol fields, and some way to determine
+ the "TCP length", both to provide the functional equivlent service
+ of IP and to be used in the TCP checksum.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [Page 51]
+
+
+ September 1981
+Transmission Control Protocol
+Functional Specification
+
+
+
+3.9. Event Processing
+
+ The processing depicted in this section is an example of one possible
+ implementation. Other implementations may have slightly different
+ processing sequences, but they should differ from those in this
+ section only in detail, not in substance.
+
+ The activity of the TCP can be characterized as responding to events.
+ The events that occur can be cast into three categories: user calls,
+ arriving segments, and timeouts. This section describes the
+ processing the TCP does in response to each of the events. In many
+ cases the processing required depends on the state of the connection.
+
+ Events that occur:
+
+ User Calls
+
+ OPEN
+ SEND
+ RECEIVE
+ CLOSE
+ ABORT
+ STATUS
+
+ Arriving Segments
+
+ SEGMENT ARRIVES
+
+ Timeouts
+
+ USER TIMEOUT
+ RETRANSMISSION TIMEOUT
+ TIME-WAIT TIMEOUT
+
+ The model of the TCP/user interface is that user commands receive an
+ immediate return and possibly a delayed response via an event or
+ pseudo interrupt. In the following descriptions, the term "signal"
+ means cause a delayed response.
+
+ Error responses are given as character strings. For example, user
+ commands referencing connections that do not exist receive "error:
+ connection not open".
+
+ Please note in the following that all arithmetic on sequence numbers,
+ acknowledgment numbers, windows, et cetera, is modulo 2**32 the size
+ of the sequence number space. Also note that "=<" means less than or
+ equal to (modulo 2**32).
+
+
+
+[Page 52]
+
+
+September 1981
+ Transmission Control Protocol
+ Functional Specification
+
+
+
+ A natural way to think about processing incoming segments is to
+ imagine that they are first tested for proper sequence number (i.e.,
+ that their contents lie in the range of the expected "receive window"
+ in the sequence number space) and then that they are generally queued
+ and processed in sequence number order.
+
+ When a segment overlaps other already received segments we reconstruct
+ the segment to contain just the new data, and adjust the header fields
+ to be consistent.
+
+ Note that if no state change is mentioned the TCP stays in the same
+ state.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [Page 53]
+
+
+ September 1981
+Transmission Control Protocol
+Functional Specification
+ OPEN Call
+
+
+
+ OPEN Call
+
+ CLOSED STATE (i.e., TCB does not exist)
+
+ Create a new transmission control block (TCB) to hold connection
+ state information. Fill in local socket identifier, foreign
+ socket, precedence, security/compartment, and user timeout
+ information. Note that some parts of the foreign socket may be
+ unspecified in a passive OPEN and are to be filled in by the
+ parameters of the incoming SYN segment. Verify the security and
+ precedence requested are allowed for this user, if not return
+ "error: precedence not allowed" or "error: security/compartment
+ not allowed." If passive enter the LISTEN state and return. If
+ active and the foreign socket is unspecified, return "error:
+ foreign socket unspecified"; if active and the foreign socket is
+ specified, issue a SYN segment. An initial send sequence number
+ (ISS) is selected. A SYN segment of the form <SEQ=ISS><CTL=SYN>
+ is sent. Set SND.UNA to ISS, SND.NXT to ISS+1, enter SYN-SENT
+ state, and return.
+
+ If the caller does not have access to the local socket specified,
+ return "error: connection illegal for this process". If there is
+ no room to create a new connection, return "error: insufficient
+ resources".
+
+ LISTEN STATE
+
+ If active and the foreign socket is specified, then change the
+ connection from passive to active, select an ISS. Send a SYN
+ segment, set SND.UNA to ISS, SND.NXT to ISS+1. Enter SYN-SENT
+ state. Data associated with SEND may be sent with SYN segment or
+ queued for transmission after entering ESTABLISHED state. The
+ urgent bit if requested in the command must be sent with the data
+ segments sent as a result of this command. If there is no room to
+ queue the request, respond with "error: insufficient resources".
+ If Foreign socket was not specified, then return "error: foreign
+ socket unspecified".
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 54]
+
+
+September 1981
+ Transmission Control Protocol
+ Functional Specification
+OPEN Call
+
+
+
+ SYN-SENT STATE
+ SYN-RECEIVED STATE
+ ESTABLISHED STATE
+ FIN-WAIT-1 STATE
+ FIN-WAIT-2 STATE
+ CLOSE-WAIT STATE
+ CLOSING STATE
+ LAST-ACK STATE
+ TIME-WAIT STATE
+
+ Return "error: connection already exists".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [Page 55]
+
+
+ September 1981
+Transmission Control Protocol
+Functional Specification
+ SEND Call
+
+
+
+ SEND Call
+
+ CLOSED STATE (i.e., TCB does not exist)
+
+ If the user does not have access to such a connection, then return
+ "error: connection illegal for this process".
+
+ Otherwise, return "error: connection does not exist".
+
+ LISTEN STATE
+
+ If the foreign socket is specified, then change the connection
+ from passive to active, select an ISS. Send a SYN segment, set
+ SND.UNA to ISS, SND.NXT to ISS+1. Enter SYN-SENT state. Data
+ associated with SEND may be sent with SYN segment or queued for
+ transmission after entering ESTABLISHED state. The urgent bit if
+ requested in the command must be sent with the data segments sent
+ as a result of this command. If there is no room to queue the
+ request, respond with "error: insufficient resources". If
+ Foreign socket was not specified, then return "error: foreign
+ socket unspecified".
+
+ SYN-SENT STATE
+ SYN-RECEIVED STATE
+
+ Queue the data for transmission after entering ESTABLISHED state.
+ If no space to queue, respond with "error: insufficient
+ resources".
+
+ ESTABLISHED STATE
+ CLOSE-WAIT STATE
+
+ Segmentize the buffer and send it with a piggybacked
+ acknowledgment (acknowledgment value = RCV.NXT). If there is
+ insufficient space to remember this buffer, simply return "error:
+ insufficient resources".
+
+ If the urgent flag is set, then SND.UP <- SND.NXT-1 and set the
+ urgent pointer in the outgoing segments.
+
+
+
+
+
+
+
+
+
+
+[Page 56]
+
+
+September 1981
+ Transmission Control Protocol
+ Functional Specification
+SEND Call
+
+
+
+ FIN-WAIT-1 STATE
+ FIN-WAIT-2 STATE
+ CLOSING STATE
+ LAST-ACK STATE
+ TIME-WAIT STATE
+
+ Return "error: connection closing" and do not service request.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [Page 57]
+
+
+ September 1981
+Transmission Control Protocol
+Functional Specification
+ RECEIVE Call
+
+
+
+ RECEIVE Call
+
+ CLOSED STATE (i.e., TCB does not exist)
+
+ If the user does not have access to such a connection, return
+ "error: connection illegal for this process".
+
+ Otherwise return "error: connection does not exist".
+
+ LISTEN STATE
+ SYN-SENT STATE
+ SYN-RECEIVED STATE
+
+ Queue for processing after entering ESTABLISHED state. If there
+ is no room to queue this request, respond with "error:
+ insufficient resources".
+
+ ESTABLISHED STATE
+ FIN-WAIT-1 STATE
+ FIN-WAIT-2 STATE
+
+ If insufficient incoming segments are queued to satisfy the
+ request, queue the request. If there is no queue space to
+ remember the RECEIVE, respond with "error: insufficient
+ resources".
+
+ Reassemble queued incoming segments into receive buffer and return
+ to user. Mark "push seen" (PUSH) if this is the case.
+
+ If RCV.UP is in advance of the data currently being passed to the
+ user notify the user of the presence of urgent data.
+
+ When the TCP takes responsibility for delivering data to the user
+ that fact must be communicated to the sender via an
+ acknowledgment. The formation of such an acknowledgment is
+ described below in the discussion of processing an incoming
+ segment.
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 58]
+
+
+September 1981
+ Transmission Control Protocol
+ Functional Specification
+RECEIVE Call
+
+
+
+ CLOSE-WAIT STATE
+
+ Since the remote side has already sent FIN, RECEIVEs must be
+ satisfied by text already on hand, but not yet delivered to the
+ user. If no text is awaiting delivery, the RECEIVE will get a
+ "error: connection closing" response. Otherwise, any remaining
+ text can be used to satisfy the RECEIVE.
+
+ CLOSING STATE
+ LAST-ACK STATE
+ TIME-WAIT STATE
+
+ Return "error: connection closing".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [Page 59]
+
+
+ September 1981
+Transmission Control Protocol
+Functional Specification
+ CLOSE Call
+
+
+
+ CLOSE Call
+
+ CLOSED STATE (i.e., TCB does not exist)
+
+ If the user does not have access to such a connection, return
+ "error: connection illegal for this process".
+
+ Otherwise, return "error: connection does not exist".
+
+ LISTEN STATE
+
+ Any outstanding RECEIVEs are returned with "error: closing"
+ responses. Delete TCB, enter CLOSED state, and return.
+
+ SYN-SENT STATE
+
+ Delete the TCB and return "error: closing" responses to any
+ queued SENDs, or RECEIVEs.
+
+ SYN-RECEIVED STATE
+
+ If no SENDs have been issued and there is no pending data to send,
+ then form a FIN segment and send it, and enter FIN-WAIT-1 state;
+ otherwise queue for processing after entering ESTABLISHED state.
+
+ ESTABLISHED STATE
+
+ Queue this until all preceding SENDs have been segmentized, then
+ form a FIN segment and send it. In any case, enter FIN-WAIT-1
+ state.
+
+ FIN-WAIT-1 STATE
+ FIN-WAIT-2 STATE
+
+ Strictly speaking, this is an error and should receive a "error:
+ connection closing" response. An "ok" response would be
+ acceptable, too, as long as a second FIN is not emitted (the first
+ FIN may be retransmitted though).
+
+
+
+
+
+
+
+
+
+
+
+[Page 60]
+
+
+September 1981
+ Transmission Control Protocol
+ Functional Specification
+CLOSE Call
+
+
+
+ CLOSE-WAIT STATE
+
+ Queue this request until all preceding SENDs have been
+ segmentized; then send a FIN segment, enter CLOSING state.
+
+ CLOSING STATE
+ LAST-ACK STATE
+ TIME-WAIT STATE
+
+ Respond with "error: connection closing".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [Page 61]
+
+
+ September 1981
+Transmission Control Protocol
+Functional Specification
+ ABORT Call
+
+
+
+ ABORT Call
+
+ CLOSED STATE (i.e., TCB does not exist)
+
+ If the user should not have access to such a connection, return
+ "error: connection illegal for this process".
+
+ Otherwise return "error: connection does not exist".
+
+ LISTEN STATE
+
+ Any outstanding RECEIVEs should be returned with "error:
+ connection reset" responses. Delete TCB, enter CLOSED state, and
+ return.
+
+ SYN-SENT STATE
+
+ All queued SENDs and RECEIVEs should be given "connection reset"
+ notification, delete the TCB, enter CLOSED state, and return.
+
+ SYN-RECEIVED STATE
+ ESTABLISHED STATE
+ FIN-WAIT-1 STATE
+ FIN-WAIT-2 STATE
+ CLOSE-WAIT STATE
+
+ Send a reset segment:
+
+ <SEQ=SND.NXT><CTL=RST>
+
+ All queued SENDs and RECEIVEs should be given "connection reset"
+ notification; all segments queued for transmission (except for the
+ RST formed above) or retransmission should be flushed, delete the
+ TCB, enter CLOSED state, and return.
+
+ CLOSING STATE
+ LAST-ACK STATE
+ TIME-WAIT STATE
+
+ Respond with "ok" and delete the TCB, enter CLOSED state, and
+ return.
+
+
+
+
+
+
+
+
+[Page 62]
+
+
+September 1981
+ Transmission Control Protocol
+ Functional Specification
+STATUS Call
+
+
+
+ STATUS Call
+
+ CLOSED STATE (i.e., TCB does not exist)
+
+ If the user should not have access to such a connection, return
+ "error: connection illegal for this process".
+
+ Otherwise return "error: connection does not exist".
+
+ LISTEN STATE
+
+ Return "state = LISTEN", and the TCB pointer.
+
+ SYN-SENT STATE
+
+ Return "state = SYN-SENT", and the TCB pointer.
+
+ SYN-RECEIVED STATE
+
+ Return "state = SYN-RECEIVED", and the TCB pointer.
+
+ ESTABLISHED STATE
+
+ Return "state = ESTABLISHED", and the TCB pointer.
+
+ FIN-WAIT-1 STATE
+
+ Return "state = FIN-WAIT-1", and the TCB pointer.
+
+ FIN-WAIT-2 STATE
+
+ Return "state = FIN-WAIT-2", and the TCB pointer.
+
+ CLOSE-WAIT STATE
+
+ Return "state = CLOSE-WAIT", and the TCB pointer.
+
+ CLOSING STATE
+
+ Return "state = CLOSING", and the TCB pointer.
+
+ LAST-ACK STATE
+
+ Return "state = LAST-ACK", and the TCB pointer.
+
+
+
+
+
+ [Page 63]
+
+
+ September 1981
+Transmission Control Protocol
+Functional Specification
+ STATUS Call
+
+
+
+ TIME-WAIT STATE
+
+ Return "state = TIME-WAIT", and the TCB pointer.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 64]
+
+
+September 1981
+ Transmission Control Protocol
+ Functional Specification
+SEGMENT ARRIVES
+
+
+
+ SEGMENT ARRIVES
+
+ If the state is CLOSED (i.e., TCB does not exist) then
+
+ all data in the incoming segment is discarded. An incoming
+ segment containing a RST is discarded. An incoming segment not
+ containing a RST causes a RST to be sent in response. The
+ acknowledgment and sequence field values are selected to make the
+ reset sequence acceptable to the TCP that sent the offending
+ segment.
+
+ If the ACK bit is off, sequence number zero is used,
+
+ <SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>
+
+ If the ACK bit is on,
+
+ <SEQ=SEG.ACK><CTL=RST>
+
+ Return.
+
+ If the state is LISTEN then
+
+ first check for an RST
+
+ An incoming RST should be ignored. Return.
+
+ second check for an ACK
+
+ Any acknowledgment is bad if it arrives on a connection still in
+ the LISTEN state. An acceptable reset segment should be formed
+ for any arriving ACK-bearing segment. The RST should be
+ formatted as follows:
+
+ <SEQ=SEG.ACK><CTL=RST>
+
+ Return.
+
+ third check for a SYN
+
+ If the SYN bit is set, check the security. If the
+ security/compartment on the incoming segment does not exactly
+ match the security/compartment in the TCB then send a reset and
+ return.
+
+ <SEQ=SEG.ACK><CTL=RST>
+
+
+
+ [Page 65]
+
+
+ September 1981
+Transmission Control Protocol
+Functional Specification
+ SEGMENT ARRIVES
+
+
+
+ If the SEG.PRC is greater than the TCB.PRC then if allowed by
+ the user and the system set TCB.PRC<-SEG.PRC, if not allowed
+ send a reset and return.
+
+ <SEQ=SEG.ACK><CTL=RST>
+
+ If the SEG.PRC is less than the TCB.PRC then continue.
+
+ Set RCV.NXT to SEG.SEQ+1, IRS is set to SEG.SEQ and any other
+ control or text should be queued for processing later. ISS
+ should be selected and a SYN segment sent of the form:
+
+ <SEQ=ISS><ACK=RCV.NXT><CTL=SYN,ACK>
+
+ SND.NXT is set to ISS+1 and SND.UNA to ISS. The connection
+ state should be changed to SYN-RECEIVED. Note that any other
+ incoming control or data (combined with SYN) will be processed
+ in the SYN-RECEIVED state, but processing of SYN and ACK should
+ not be repeated. If the listen was not fully specified (i.e.,
+ the foreign socket was not fully specified), then the
+ unspecified fields should be filled in now.
+
+ fourth other text or control
+
+ Any other control or text-bearing segment (not containing SYN)
+ must have an ACK and thus would be discarded by the ACK
+ processing. An incoming RST segment could not be valid, since
+ it could not have been sent in response to anything sent by this
+ incarnation of the connection. So you are unlikely to get here,
+ but if you do, drop the segment, and return.
+
+ If the state is SYN-SENT then
+
+ first check the ACK bit
+
+ If the ACK bit is set
+
+ If SEG.ACK =< ISS, or SEG.ACK > SND.NXT, send a reset (unless
+ the RST bit is set, if so drop the segment and return)
+
+ <SEQ=SEG.ACK><CTL=RST>
+
+ and discard the segment. Return.
+
+ If SND.UNA =< SEG.ACK =< SND.NXT then the ACK is acceptable.
+
+ second check the RST bit
+
+
+[Page 66]
+
+
+September 1981
+ Transmission Control Protocol
+ Functional Specification
+SEGMENT ARRIVES
+
+
+
+ If the RST bit is set
+
+ If the ACK was acceptable then signal the user "error:
+ connection reset", drop the segment, enter CLOSED state,
+ delete TCB, and return. Otherwise (no ACK) drop the segment
+ and return.
+
+ third check the security and precedence
+
+ If the security/compartment in the segment does not exactly
+ match the security/compartment in the TCB, send a reset
+
+ If there is an ACK
+
+ <SEQ=SEG.ACK><CTL=RST>
+
+ Otherwise
+
+ <SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>
+
+ If there is an ACK
+
+ The precedence in the segment must match the precedence in the
+ TCB, if not, send a reset
+
+ <SEQ=SEG.ACK><CTL=RST>
+
+ If there is no ACK
+
+ If the precedence in the segment is higher than the precedence
+ in the TCB then if allowed by the user and the system raise
+ the precedence in the TCB to that in the segment, if not
+ allowed to raise the prec then send a reset.
+
+ <SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>
+
+ If the precedence in the segment is lower than the precedence
+ in the TCB continue.
+
+ If a reset was sent, discard the segment and return.
+
+ fourth check the SYN bit
+
+ This step should be reached only if the ACK is ok, or there is
+ no ACK, and it the segment did not contain a RST.
+
+ If the SYN bit is on and the security/compartment and precedence
+
+
+ [Page 67]
+
+
+ September 1981
+Transmission Control Protocol
+Functional Specification
+ SEGMENT ARRIVES
+
+
+
+ are acceptable then, RCV.NXT is set to SEG.SEQ+1, IRS is set to
+ SEG.SEQ. SND.UNA should be advanced to equal SEG.ACK (if there
+ is an ACK), and any segments on the retransmission queue which
+ are thereby acknowledged should be removed.
+
+ If SND.UNA > ISS (our SYN has been ACKed), change the connection
+ state to ESTABLISHED, form an ACK segment
+
+ <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
+
+ and send it. Data or controls which were queued for
+ transmission may be included. If there are other controls or
+ text in the segment then continue processing at the sixth step
+ below where the URG bit is checked, otherwise return.
+
+ Otherwise enter SYN-RECEIVED, form a SYN,ACK segment
+
+ <SEQ=ISS><ACK=RCV.NXT><CTL=SYN,ACK>
+
+ and send it. If there are other controls or text in the
+ segment, queue them for processing after the ESTABLISHED state
+ has been reached, return.
+
+ fifth, if neither of the SYN or RST bits is set then drop the
+ segment and return.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 68]
+
+
+September 1981
+ Transmission Control Protocol
+ Functional Specification
+SEGMENT ARRIVES
+
+
+
+ Otherwise,
+
+ first check sequence number
+
+ SYN-RECEIVED STATE
+ ESTABLISHED STATE
+ FIN-WAIT-1 STATE
+ FIN-WAIT-2 STATE
+ CLOSE-WAIT STATE
+ CLOSING STATE
+ LAST-ACK STATE
+ TIME-WAIT STATE
+
+ Segments are processed in sequence. Initial tests on arrival
+ are used to discard old duplicates, but further processing is
+ done in SEG.SEQ order. If a segment's contents straddle the
+ boundary between old and new, only the new parts should be
+ processed.
+
+ There are four cases for the acceptability test for an incoming
+ segment:
+
+ Segment Receive Test
+ Length Window
+ ------- ------- -------------------------------------------
+
+ 0 0 SEG.SEQ = RCV.NXT
+
+ 0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND
+
+ >0 0 not acceptable
+
+ >0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND
+ or RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND
+
+ If the RCV.WND is zero, no segments will be acceptable, but
+ special allowance should be made to accept valid ACKs, URGs and
+ RSTs.
+
+ If an incoming segment is not acceptable, an acknowledgment
+ should be sent in reply (unless the RST bit is set, if so drop
+ the segment and return):
+
+ <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
+
+ After sending the acknowledgment, drop the unacceptable segment
+ and return.
+
+
+ [Page 69]
+
+
+ September 1981
+Transmission Control Protocol
+Functional Specification
+ SEGMENT ARRIVES
+
+
+
+ In the following it is assumed that the segment is the idealized
+ segment that begins at RCV.NXT and does not exceed the window.
+ One could tailor actual segments to fit this assumption by
+ trimming off any portions that lie outside the window (including
+ SYN and FIN), and only processing further if the segment then
+ begins at RCV.NXT. Segments with higher begining sequence
+ numbers may be held for later processing.
+
+ second check the RST bit,
+
+ SYN-RECEIVED STATE
+
+ If the RST bit is set
+
+ If this connection was initiated with a passive OPEN (i.e.,
+ came from the LISTEN state), then return this connection to
+ LISTEN state and return. The user need not be informed. If
+ this connection was initiated with an active OPEN (i.e., came
+ from SYN-SENT state) then the connection was refused, signal
+ the user "connection refused". In either case, all segments
+ on the retransmission queue should be removed. And in the
+ active OPEN case, enter the CLOSED state and delete the TCB,
+ and return.
+
+ ESTABLISHED
+ FIN-WAIT-1
+ FIN-WAIT-2
+ CLOSE-WAIT
+
+ If the RST bit is set then, any outstanding RECEIVEs and SEND
+ should receive "reset" responses. All segment queues should be
+ flushed. Users should also receive an unsolicited general
+ "connection reset" signal. Enter the CLOSED state, delete the
+ TCB, and return.
+
+ CLOSING STATE
+ LAST-ACK STATE
+ TIME-WAIT
+
+ If the RST bit is set then, enter the CLOSED state, delete the
+ TCB, and return.
+
+
+
+
+
+
+
+
+[Page 70]
+
+
+September 1981
+ Transmission Control Protocol
+ Functional Specification
+SEGMENT ARRIVES
+
+
+
+ third check security and precedence
+
+ SYN-RECEIVED
+
+ If the security/compartment and precedence in the segment do not
+ exactly match the security/compartment and precedence in the TCB
+ then send a reset, and return.
+
+ ESTABLISHED STATE
+
+ If the security/compartment and precedence in the segment do not
+ exactly match the security/compartment and precedence in the TCB
+ then send a reset, any outstanding RECEIVEs and SEND should
+ receive "reset" responses. All segment queues should be
+ flushed. Users should also receive an unsolicited general
+ "connection reset" signal. Enter the CLOSED state, delete the
+ TCB, and return.
+
+ Note this check is placed following the sequence check to prevent
+ a segment from an old connection between these ports with a
+ different security or precedence from causing an abort of the
+ current connection.
+
+ fourth, check the SYN bit,
+
+ SYN-RECEIVED
+ ESTABLISHED STATE
+ FIN-WAIT STATE-1
+ FIN-WAIT STATE-2
+ CLOSE-WAIT STATE
+ CLOSING STATE
+ LAST-ACK STATE
+ TIME-WAIT STATE
+
+ If the SYN is in the window it is an error, send a reset, any
+ outstanding RECEIVEs and SEND should receive "reset" responses,
+ all segment queues should be flushed, the user should also
+ receive an unsolicited general "connection reset" signal, enter
+ the CLOSED state, delete the TCB, and return.
+
+ If the SYN is not in the window this step would not be reached
+ and an ack would have been sent in the first step (sequence
+ number check).
+
+
+
+
+
+
+ [Page 71]
+
+
+ September 1981
+Transmission Control Protocol
+Functional Specification
+ SEGMENT ARRIVES
+
+
+
+ fifth check the ACK field,
+
+ if the ACK bit is off drop the segment and return
+
+ if the ACK bit is on
+
+ SYN-RECEIVED STATE
+
+ If SND.UNA =< SEG.ACK =< SND.NXT then enter ESTABLISHED state
+ and continue processing.
+
+ If the segment acknowledgment is not acceptable, form a
+ reset segment,
+
+ <SEQ=SEG.ACK><CTL=RST>
+
+ and send it.
+
+ ESTABLISHED STATE
+
+ If SND.UNA < SEG.ACK =< SND.NXT then, set SND.UNA <- SEG.ACK.
+ Any segments on the retransmission queue which are thereby
+ entirely acknowledged are removed. Users should receive
+ positive acknowledgments for buffers which have been SENT and
+ fully acknowledged (i.e., SEND buffer should be returned with
+ "ok" response). If the ACK is a duplicate
+ (SEG.ACK < SND.UNA), it can be ignored. If the ACK acks
+ something not yet sent (SEG.ACK > SND.NXT) then send an ACK,
+ drop the segment, and return.
+
+ If SND.UNA < SEG.ACK =< SND.NXT, the send window should be
+ updated. If (SND.WL1 < SEG.SEQ or (SND.WL1 = SEG.SEQ and
+ SND.WL2 =< SEG.ACK)), set SND.WND <- SEG.WND, set
+ SND.WL1 <- SEG.SEQ, and set SND.WL2 <- SEG.ACK.
+
+ Note that SND.WND is an offset from SND.UNA, that SND.WL1
+ records the sequence number of the last segment used to update
+ SND.WND, and that SND.WL2 records the acknowledgment number of
+ the last segment used to update SND.WND. The check here
+ prevents using old segments to update the window.
+
+
+
+
+
+
+
+
+
+[Page 72]
+
+
+September 1981
+ Transmission Control Protocol
+ Functional Specification
+SEGMENT ARRIVES
+
+
+
+ FIN-WAIT-1 STATE
+
+ In addition to the processing for the ESTABLISHED state, if
+ our FIN is now acknowledged then enter FIN-WAIT-2 and continue
+ processing in that state.
+
+ FIN-WAIT-2 STATE
+
+ In addition to the processing for the ESTABLISHED state, if
+ the retransmission queue is empty, the user's CLOSE can be
+ acknowledged ("ok") but do not delete the TCB.
+
+ CLOSE-WAIT STATE
+
+ Do the same processing as for the ESTABLISHED state.
+
+ CLOSING STATE
+
+ In addition to the processing for the ESTABLISHED state, if
+ the ACK acknowledges our FIN then enter the TIME-WAIT state,
+ otherwise ignore the segment.
+
+ LAST-ACK STATE
+
+ The only thing that can arrive in this state is an
+ acknowledgment of our FIN. If our FIN is now acknowledged,
+ delete the TCB, enter the CLOSED state, and return.
+
+ TIME-WAIT STATE
+
+ The only thing that can arrive in this state is a
+ retransmission of the remote FIN. Acknowledge it, and restart
+ the 2 MSL timeout.
+
+ sixth, check the URG bit,
+
+ ESTABLISHED STATE
+ FIN-WAIT-1 STATE
+ FIN-WAIT-2 STATE
+
+ If the URG bit is set, RCV.UP <- max(RCV.UP,SEG.UP), and signal
+ the user that the remote side has urgent data if the urgent
+ pointer (RCV.UP) is in advance of the data consumed. If the
+ user has already been signaled (or is still in the "urgent
+ mode") for this continuous sequence of urgent data, do not
+ signal the user again.
+
+
+
+ [Page 73]
+
+
+ September 1981
+Transmission Control Protocol
+Functional Specification
+ SEGMENT ARRIVES
+
+
+
+ CLOSE-WAIT STATE
+ CLOSING STATE
+ LAST-ACK STATE
+ TIME-WAIT
+
+ This should not occur, since a FIN has been received from the
+ remote side. Ignore the URG.
+
+ seventh, process the segment text,
+
+ ESTABLISHED STATE
+ FIN-WAIT-1 STATE
+ FIN-WAIT-2 STATE
+
+ Once in the ESTABLISHED state, it is possible to deliver segment
+ text to user RECEIVE buffers. Text from segments can be moved
+ into buffers until either the buffer is full or the segment is
+ empty. If the segment empties and carries an PUSH flag, then
+ the user is informed, when the buffer is returned, that a PUSH
+ has been received.
+
+ When the TCP takes responsibility for delivering the data to the
+ user it must also acknowledge the receipt of the data.
+
+ Once the TCP takes responsibility for the data it advances
+ RCV.NXT over the data accepted, and adjusts RCV.WND as
+ apporopriate to the current buffer availability. The total of
+ RCV.NXT and RCV.WND should not be reduced.
+
+ Please note the window management suggestions in section 3.7.
+
+ Send an acknowledgment of the form:
+
+ <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
+
+ This acknowledgment should be piggybacked on a segment being
+ transmitted if possible without incurring undue delay.
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 74]
+
+
+September 1981
+ Transmission Control Protocol
+ Functional Specification
+SEGMENT ARRIVES
+
+
+
+ CLOSE-WAIT STATE
+ CLOSING STATE
+ LAST-ACK STATE
+ TIME-WAIT STATE
+
+ This should not occur, since a FIN has been received from the
+ remote side. Ignore the segment text.
+
+ eighth, check the FIN bit,
+
+ Do not process the FIN if the state is CLOSED, LISTEN or SYN-SENT
+ since the SEG.SEQ cannot be validated; drop the segment and
+ return.
+
+ If the FIN bit is set, signal the user "connection closing" and
+ return any pending RECEIVEs with same message, advance RCV.NXT
+ over the FIN, and send an acknowledgment for the FIN. Note that
+ FIN implies PUSH for any segment text not yet delivered to the
+ user.
+
+ SYN-RECEIVED STATE
+ ESTABLISHED STATE
+
+ Enter the CLOSE-WAIT state.
+
+ FIN-WAIT-1 STATE
+
+ If our FIN has been ACKed (perhaps in this segment), then
+ enter TIME-WAIT, start the time-wait timer, turn off the other
+ timers; otherwise enter the CLOSING state.
+
+ FIN-WAIT-2 STATE
+
+ Enter the TIME-WAIT state. Start the time-wait timer, turn
+ off the other timers.
+
+ CLOSE-WAIT STATE
+
+ Remain in the CLOSE-WAIT state.
+
+ CLOSING STATE
+
+ Remain in the CLOSING state.
+
+ LAST-ACK STATE
+
+ Remain in the LAST-ACK state.
+
+
+ [Page 75]
+
+
+ September 1981
+Transmission Control Protocol
+Functional Specification
+ SEGMENT ARRIVES
+
+
+
+ TIME-WAIT STATE
+
+ Remain in the TIME-WAIT state. Restart the 2 MSL time-wait
+ timeout.
+
+ and return.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 76]
+
+
+September 1981
+ Transmission Control Protocol
+ Functional Specification
+USER TIMEOUT
+
+
+
+ USER TIMEOUT
+
+ For any state if the user timeout expires, flush all queues, signal
+ the user "error: connection aborted due to user timeout" in general
+ and for any outstanding calls, delete the TCB, enter the CLOSED
+ state and return.
+
+ RETRANSMISSION TIMEOUT
+
+ For any state if the retransmission timeout expires on a segment in
+ the retransmission queue, send the segment at the front of the
+ retransmission queue again, reinitialize the retransmission timer,
+ and return.
+
+ TIME-WAIT TIMEOUT
+
+ If the time-wait timeout expires on a connection delete the TCB,
+ enter the CLOSED state and return.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [Page 77]
+
+
+ September 1981
+Transmission Control Protocol
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 78]
+
+
+September 1981
+ Transmission Control Protocol
+
+
+
+ GLOSSARY
+
+
+
+1822
+ BBN Report 1822, "The Specification of the Interconnection of
+ a Host and an IMP". The specification of interface between a
+ host and the ARPANET.
+
+ACK
+ A control bit (acknowledge) occupying no sequence space, which
+ indicates that the acknowledgment field of this segment
+ specifies the next sequence number the sender of this segment
+ is expecting to receive, hence acknowledging receipt of all
+ previous sequence numbers.
+
+ARPANET message
+ The unit of transmission between a host and an IMP in the
+ ARPANET. The maximum size is about 1012 octets (8096 bits).
+
+ARPANET packet
+ A unit of transmission used internally in the ARPANET between
+ IMPs. The maximum size is about 126 octets (1008 bits).
+
+connection
+ A logical communication path identified by a pair of sockets.
+
+datagram
+ A message sent in a packet switched computer communications
+ network.
+
+Destination Address
+ The destination address, usually the network and host
+ identifiers.
+
+FIN
+ A control bit (finis) occupying one sequence number, which
+ indicates that the sender will send no more data or control
+ occupying sequence space.
+
+fragment
+ A portion of a logical unit of data, in particular an internet
+ fragment is a portion of an internet datagram.
+
+FTP
+ A file transfer protocol.
+
+
+
+
+
+ [Page 79]
+
+
+ September 1981
+Transmission Control Protocol
+Glossary
+
+
+
+header
+ Control information at the beginning of a message, segment,
+ fragment, packet or block of data.
+
+host
+ A computer. In particular a source or destination of messages
+ from the point of view of the communication network.
+
+Identification
+ An Internet Protocol field. This identifying value assigned
+ by the sender aids in assembling the fragments of a datagram.
+
+IMP
+ The Interface Message Processor, the packet switch of the
+ ARPANET.
+
+internet address
+ A source or destination address specific to the host level.
+
+internet datagram
+ The unit of data exchanged between an internet module and the
+ higher level protocol together with the internet header.
+
+internet fragment
+ A portion of the data of an internet datagram with an internet
+ header.
+
+IP
+ Internet Protocol.
+
+IRS
+ The Initial Receive Sequence number. The first sequence
+ number used by the sender on a connection.
+
+ISN
+ The Initial Sequence Number. The first sequence number used
+ on a connection, (either ISS or IRS). Selected on a clock
+ based procedure.
+
+ISS
+ The Initial Send Sequence number. The first sequence number
+ used by the sender on a connection.
+
+leader
+ Control information at the beginning of a message or block of
+ data. In particular, in the ARPANET, the control information
+ on an ARPANET message at the host-IMP interface.
+
+
+
+[Page 80]
+
+
+September 1981
+ Transmission Control Protocol
+ Glossary
+
+
+
+left sequence
+ This is the next sequence number to be acknowledged by the
+ data receiving TCP (or the lowest currently unacknowledged
+ sequence number) and is sometimes referred to as the left edge
+ of the send window.
+
+local packet
+ The unit of transmission within a local network.
+
+module
+ An implementation, usually in software, of a protocol or other
+ procedure.
+
+MSL
+ Maximum Segment Lifetime, the time a TCP segment can exist in
+ the internetwork system. Arbitrarily defined to be 2 minutes.
+
+octet
+ An eight bit byte.
+
+Options
+ An Option field may contain several options, and each option
+ may be several octets in length. The options are used
+ primarily in testing situations; for example, to carry
+ timestamps. Both the Internet Protocol and TCP provide for
+ options fields.
+
+packet
+ A package of data with a header which may or may not be
+ logically complete. More often a physical packaging than a
+ logical packaging of data.
+
+port
+ The portion of a socket that specifies which logical input or
+ output channel of a process is associated with the data.
+
+process
+ A program in execution. A source or destination of data from
+ the point of view of the TCP or other host-to-host protocol.
+
+PUSH
+ A control bit occupying no sequence space, indicating that
+ this segment contains data that must be pushed through to the
+ receiving user.
+
+RCV.NXT
+ receive next sequence number
+
+
+
+ [Page 81]
+
+
+ September 1981
+Transmission Control Protocol
+Glossary
+
+
+
+RCV.UP
+ receive urgent pointer
+
+RCV.WND
+ receive window
+
+receive next sequence number
+ This is the next sequence number the local TCP is expecting to
+ receive.
+
+receive window
+ This represents the sequence numbers the local (receiving) TCP
+ is willing to receive. Thus, the local TCP considers that
+ segments overlapping the range RCV.NXT to
+ RCV.NXT + RCV.WND - 1 carry acceptable data or control.
+ Segments containing sequence numbers entirely outside of this
+ range are considered duplicates and discarded.
+
+RST
+ A control bit (reset), occupying no sequence space, indicating
+ that the receiver should delete the connection without further
+ interaction. The receiver can determine, based on the
+ sequence number and acknowledgment fields of the incoming
+ segment, whether it should honor the reset command or ignore
+ it. In no case does receipt of a segment containing RST give
+ rise to a RST in response.
+
+RTP
+ Real Time Protocol: A host-to-host protocol for communication
+ of time critical information.
+
+SEG.ACK
+ segment acknowledgment
+
+SEG.LEN
+ segment length
+
+SEG.PRC
+ segment precedence value
+
+SEG.SEQ
+ segment sequence
+
+SEG.UP
+ segment urgent pointer field
+
+
+
+
+
+[Page 82]
+
+
+September 1981
+ Transmission Control Protocol
+ Glossary
+
+
+
+SEG.WND
+ segment window field
+
+segment
+ A logical unit of data, in particular a TCP segment is the
+ unit of data transfered between a pair of TCP modules.
+
+segment acknowledgment
+ The sequence number in the acknowledgment field of the
+ arriving segment.
+
+segment length
+ The amount of sequence number space occupied by a segment,
+ including any controls which occupy sequence space.
+
+segment sequence
+ The number in the sequence field of the arriving segment.
+
+send sequence
+ This is the next sequence number the local (sending) TCP will
+ use on the connection. It is initially selected from an
+ initial sequence number curve (ISN) and is incremented for
+ each octet of data or sequenced control transmitted.
+
+send window
+ This represents the sequence numbers which the remote
+ (receiving) TCP is willing to receive. It is the value of the
+ window field specified in segments from the remote (data
+ receiving) TCP. The range of new sequence numbers which may
+ be emitted by a TCP lies between SND.NXT and
+ SND.UNA + SND.WND - 1. (Retransmissions of sequence numbers
+ between SND.UNA and SND.NXT are expected, of course.)
+
+SND.NXT
+ send sequence
+
+SND.UNA
+ left sequence
+
+SND.UP
+ send urgent pointer
+
+SND.WL1
+ segment sequence number at last window update
+
+SND.WL2
+ segment acknowledgment number at last window update
+
+
+
+ [Page 83]
+
+
+ September 1981
+Transmission Control Protocol
+Glossary
+
+
+
+SND.WND
+ send window
+
+socket
+ An address which specifically includes a port identifier, that
+ is, the concatenation of an Internet Address with a TCP port.
+
+Source Address
+ The source address, usually the network and host identifiers.
+
+SYN
+ A control bit in the incoming segment, occupying one sequence
+ number, used at the initiation of a connection, to indicate
+ where the sequence numbering will start.
+
+TCB
+ Transmission control block, the data structure that records
+ the state of a connection.
+
+TCB.PRC
+ The precedence of the connection.
+
+TCP
+ Transmission Control Protocol: A host-to-host protocol for
+ reliable communication in internetwork environments.
+
+TOS
+ Type of Service, an Internet Protocol field.
+
+Type of Service
+ An Internet Protocol field which indicates the type of service
+ for this internet fragment.
+
+URG
+ A control bit (urgent), occupying no sequence space, used to
+ indicate that the receiving user should be notified to do
+ urgent processing as long as there is data to be consumed with
+ sequence numbers less than the value indicated in the urgent
+ pointer.
+
+urgent pointer
+ A control field meaningful only when the URG bit is on. This
+ field communicates the value of the urgent pointer which
+ indicates the data octet associated with the sending user's
+ urgent call.
+
+
+
+
+
+[Page 84]
+
+
+September 1981
+ Transmission Control Protocol
+
+
+
+ REFERENCES
+
+
+
+[1] Cerf, V., and R. Kahn, "A Protocol for Packet Network
+ Intercommunication", IEEE Transactions on Communications,
+ Vol. COM-22, No. 5, pp 637-648, May 1974.
+
+[2] Postel, J. (ed.), "Internet Protocol - DARPA Internet Program
+ Protocol Specification", RFC 791, USC/Information Sciences
+ Institute, September 1981.
+
+[3] Dalal, Y. and C. Sunshine, "Connection Management in Transport
+ Protocols", Computer Networks, Vol. 2, No. 6, pp. 454-473,
+ December 1978.
+
+[4] Postel, J., "Assigned Numbers", RFC 790, USC/Information Sciences
+ Institute, September 1981.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [Page 85]
+