summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
Diffstat
-rw-r--r--accel-pptpd/ppp.h15
-rw-r--r--accel-pptpd/ppp_fsm.h14
-rw-r--r--accel-pptpd/ppp_lcp.c136
-rw-r--r--doc/README15
-rw-r--r--doc/README.Reference15
-rw-r--r--doc/ms-chap.txt1139
-rw-r--r--doc/pptp-draft.txt3472
-rw-r--r--doc/rfc1661.txt2976
-rw-r--r--doc/rfc1662.txt1436
-rw-r--r--doc/rfc1701.txt451
-rw-r--r--doc/rfc1702.txt227
-rw-r--r--doc/rfc1990.txt1347
-rw-r--r--doc/rfc791.txt2887
-rw-r--r--doc/rfc793.txt5247
14 files changed, 19345 insertions, 32 deletions
diff --git a/accel-pptpd/ppp.h b/accel-pptpd/ppp.h
index e640229..8e8558b 100644
--- a/accel-pptpd/ppp.h
+++ b/accel-pptpd/ppp.h
@@ -54,18 +54,11 @@ struct ppp_t
char *chan_name;
+ //options
int mtu,mru;
- int require_mppe:1;
- int require_pap:1;
- int require_chap:1;
- int require_mschap:1;
- int require_mschap_v2:1;
-
- int allow_mppe:1;
- int allow_pap:1;
- int allow_chap:1;
- int allow_mschap:1;
- int allow_mschap_v2:1;
+ int accomp; // 0 - disabled, 1 - enable, 2 - allow, disabled, 3 - allow,enabled
+ int pcomp; // 0 - disabled, 1 - enable, 2 - allow, disabled, 3 - allow,enabled
+ //
int log:1;
diff --git a/accel-pptpd/ppp_fsm.h b/accel-pptpd/ppp_fsm.h
index f07735d..c4430c4 100644
--- a/accel-pptpd/ppp_fsm.h
+++ b/accel-pptpd/ppp_fsm.h
@@ -21,11 +21,17 @@ struct ppp_hdr_t;
struct lcp_options_t
{
+ int mtu;
int mru;
- int auth;
- int magic;
- int accomp;
- int pcomp;
+ int accomp; // 0 - disabled, 1 - enable, 2 - allow, disabled, 3 - allow,enabled
+ int pcomp; // 0 - disabled, 1 - enable, 2 - allow, disabled, 3 - allow,enabled
+ int auth[3]; // 0 - none, 1 - pap, 2 - eap, 3 - mschap
+ // negotiated options;
+ int neg_mru;
+ int neg_mtu;
+ int neg_accomp; // -1 - rejected
+ int neg_pcomp;
+ int neg_auth;
};
struct ppp_layer_t
diff --git a/accel-pptpd/ppp_lcp.c b/accel-pptpd/ppp_lcp.c
index 8f9c88b..8b4e477 100644
--- a/accel-pptpd/ppp_lcp.c
+++ b/accel-pptpd/ppp_lcp.c
@@ -13,7 +13,7 @@
char* accomp="allow,disabled";
char* pcomp="allow,disabled";
-char* auth="pap,mschap-v2";
+char* auth="pap,eap,mschap-v2";
char* mppe="allow,disabled";
char* pwdb="radius";
@@ -25,9 +25,9 @@ char* pwdb="radius";
#define CI_ASYNCMAP 2 /* Async Control Character Map */
#define CI_AUTHTYPE 3 /* Authentication Type */
#define CI_QUALITY 4 /* Quality Protocol */
-#define CI_MAGICNUMBER 5 /* Magic Number */
-#define CI_PCOMPRESSION 7 /* Protocol Field Compression */
-#define CI_ACCOMPRESSION 8 /* Address/Control Field Compression */
+#define CI_MAGIC 5 /* Magic Number */
+#define CI_PCOMP 7 /* Protocol Field Compression */
+#define CI_ACCOMP 8 /* Address/Control Field Compression */
#define CI_FCSALTERN 9 /* FCS-Alternatives */
#define CI_SDP 10 /* Self-Describing-Pad */
#define CI_NUMBERED 11 /* Numbered-Mode */
@@ -44,6 +44,33 @@ char* pwdb="radius";
#define CI_I18N 28 /* Internationalization */
#define CI_SDL 29 /* Simple Data Link */
+struct lcp_hdr_t
+{
+ uint8_t code;
+ uint8_t id;
+ uint16_t len;
+} __attribute__((packed));
+struct lcp_opt_hdr_t
+{
+ uint8_t type;
+ uint8_t len;
+} __attribute__((packed));
+struct lcp_opt8_t
+{
+ struct lcp_opt_hdr_t hdr;
+ uint8_t val;
+} __attribute__((packed));
+struct lcp_opt16_t
+{
+ struct lcp_opt_hdr_t hdr;
+ uint16_t val;
+} __attribute__((packed));
+struct lcp_opt32_t
+{
+ struct lcp_opt_hdr_t hdr;
+ uint32_t val;
+} __attribute__((packed));
+
/*static void layer_up(struct ppp_layer_t*);
static void layer_down(struct ppp_layer_t*);
static void layer_started(struct ppp_layer_t*);
@@ -109,6 +136,54 @@ static void layer_finished(struct ppp_layer_t*)
}*/
static void send_conf_req(struct ppp_layer_t*l)
{
+ uint8_t buf[128],*ptr;
+ struct lcp_opt_hdr_t *opt0;
+ struct lcp_opt8_t *opt8;
+ struct lcp_opt16_t *opt16;
+ struct lcp_opt24_t *opt24;
+ struct lcp_hdr_t *lcp_hdr=(struct lcp_hdr_t*)ptr; ptr+=sizeof(*lcp_hdr);
+
+ log_msg("send [LCP ConfReq");
+ lcp_hdr->code=CONFREQ;
+ lcp_hdr->id=++l->seq;
+ lcp_hdr->len=0;
+ log_msg(" id=%x",lcp_hdr->id);
+
+ //mru
+ opt16=(struct lcp_opt16_t*)ptr; ptr+=sizeof(*opt16);
+ opt16.hdr.type=CI_MRU;
+ opt16.hdr.len=4;
+ opt16.val=htons(l->options.lcp.mtu);
+ log_msg(" <mru %i>",l->options.lcp.mtu);
+
+ //auth
+
+ //magic
+ opt32=(struct lcp_opt32_t*)ptr; ptr+=sizeof(*opt32);
+ opt32.hdr.type=CI_MAGIC;
+ opt32.hdr.len=6;
+ opt32.val=htonl(l->options.lcp.magic);
+ log_msg(" <magic %x>",l->options.lcp.magic);
+
+
+ //pcomp
+ if (l->options.lcp.pcomp==1 || (l->options.lcp.pcomp==3 && l->options.lcp.neg_pcomp!=-1))
+ {
+ opt0=(struct lcp_opt_hdr_t*)ptr; ptr+=sizeof(*opt0);
+ opt0.type=CI_PCOMP;
+ opt0.len=2;
+ log_msg(" <pcomp>");
+ }
+
+ //acccomp
+ if (l->options.lcp.accomp==1 || (l->options.lcp.accomp==3 && l->options.lcp.neg_accomp!=-1))
+ {
+ opt0=(struct lcp_opt_hdr_t*)ptr; ptr+=sizeof(*opt0);
+ opt0.type=CI_ACCOMP;
+ opt0.len=2;
+ log_msg(" <accomp>");
+ }
+ log_msg("\n");
}
static void send_conf_ack(struct ppp_layer_t*l)
{
@@ -120,20 +195,30 @@ static void send_conf_rej(struct ppp_layer_t*l)
{
}
-static int lcp_recv_conf_req(struct ppp_layer_t*l,u_int8_t *data,int size)
+static int lcp_recv_conf_req(struct ppp_layer_t*l,uint8_t *data,int size)
{
- struct ppp_opt_t *opt;
+ struct lcp_opt_hdr_t *opt;
+ struct lcp_opt8_t *opt8;
+ struct lcp_opt16_t *opt16;
+ struct lcp_opt32_t *opt32;
+ int ret=0;
+
+ log_debug("recv [LCP ConfReq id=%x",l->recv_id);
+
while(size)
{
- opt=(struct ppp_opt_t *)data;
+ opt=(struct lcp_opt_hdr_t *)data;
switch(opt->type)
{
case CI_MRU:
- l->options.lcp.mru=*(u_int16_t*)data;
+ opt16=(struct lcp_opt16_t*)data;
+ l->options.lcp.neg_mru=ntohs(opt16.val);
+ log_debug(" <mru %i>",l->options.lcp.neg_mru);
break;
case CI_ASYNCMAP:
+ log_debug(" <asyncmap ...>");
break;
- case CI_AUTHTYPE:
+ /*case CI_AUTHTYPE:
if (l->ppp->log) log_msg("<auth ");
switch(*(u_int16_t*)data)
{
@@ -146,10 +231,10 @@ static int lcp_recv_conf_req(struct ppp_layer_t*l,u_int8_t *data,int size)
case PPP_CHAP:
if (l->ppp->log) log_msg("chap");
break;
- /*switch(data[4])
+ switch(data[4])
{
case
- }*/
+ }
default:
if (l->ppp->log) log_msg("unknown");
return -1;
@@ -161,17 +246,34 @@ static int lcp_recv_conf_req(struct ppp_layer_t*l,u_int8_t *data,int size)
log_error("loop detected\n");
return -1;
}
+ break;*/
+ case CI_PCOMP:
+ log_debug(" <pcomp>");
+ if (l->options.lcp.pcomp>=1) l->options.lcp.neg_pcomp=1;
+ else {
+ l->options.lcp.neg_pcomp=-2;
+ ret=-1;
+ }
+ break;
+ case CI_ACCOMP:
+ log_debug(" <accomp>");
+ if (l->options.lcp.accomp>=1) l->options.lcp.neg_accomp=1;
+ else {
+ l->options.lcp.neg_accomp=-2;
+ ret=-1;
+ }
break;
- case CI_PCOMPRESSION:
- case CI_ACCOMPRESSION:
}
+ data+=opt->len;
+ size-=opt->len;
}
- return 0;
+ log_debug("\n");
+ return ret;
}
static void lcp_recv(struct ppp_layer_t*l)
{
- struct ppp_hdr_t *hdr;
+ struct lcp_hdr_t *hdr;
if (l->ppp->in_buf_size-2<PPP_HEADERLEN)
{
@@ -179,8 +281,8 @@ static void lcp_recv(struct ppp_layer_t*l)
return;
}
- hdr=(struct ppp_hdr_t *)(l->ppp->in_buf+2);
- if (hdr->len<PPP_HEADERLEN)
+ hdr=(struct lcp_hdr_t *)(l->ppp->in_buf+2);
+ if (ntohs(hdr->len)<PPP_HEADERLEN)
{
log_debug("LCP: short packet received\n");
return;
diff --git a/doc/README b/doc/README
new file mode 100644
index 0000000..a76719b
--- /dev/null
+++ b/doc/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/doc/README.Reference b/doc/README.Reference
new file mode 100644
index 0000000..a76719b
--- /dev/null
+++ b/doc/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/doc/ms-chap.txt b/doc/ms-chap.txt
new file mode 100644
index 0000000..f009400
--- /dev/null
+++ b/doc/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/doc/pptp-draft.txt b/doc/pptp-draft.txt
new file mode 100644
index 0000000..f58701b
--- /dev/null
+++ b/doc/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/doc/rfc1661.txt b/doc/rfc1661.txt
new file mode 100644
index 0000000..02112bd
--- /dev/null
+++ b/doc/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/doc/rfc1662.txt b/doc/rfc1662.txt
new file mode 100644
index 0000000..5a5b214
--- /dev/null
+++ b/doc/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/doc/rfc1701.txt b/doc/rfc1701.txt
new file mode 100644
index 0000000..60a0e9b
--- /dev/null
+++ b/doc/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/doc/rfc1702.txt b/doc/rfc1702.txt
new file mode 100644
index 0000000..50b57ae
--- /dev/null
+++ b/doc/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/doc/rfc1990.txt b/doc/rfc1990.txt
new file mode 100644
index 0000000..a4f7ffe
--- /dev/null
+++ b/doc/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/doc/rfc791.txt b/doc/rfc791.txt
new file mode 100644
index 0000000..5952d0b
--- /dev/null
+++ b/doc/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/doc/rfc793.txt b/doc/rfc793.txt
new file mode 100644
index 0000000..603a78c
--- /dev/null
+++ b/doc/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]
+
generated by cgit v1.2.3 (git 2.39.1) at 2024-10-17 21:51:24 +0000