diff options
| author | Kozlov Dmitry <dima@server> | 2010-08-03 17:11:50 +0400 |
|---|---|---|
| committer | Kozlov Dmitry <dima@server> | 2010-08-03 17:11:50 +0400 |
| commit | 8a9babb739f2a9da045c749718bbe85aad5f0dd3 (patch) | |
| tree | c016ab68af0d54223a3716cd7b0508b2cb0291dd | |
| parent | 5a2d6079eba1c7e2a9479cb10d714b5a97bbfe4f (diff) | |
| download | accel-ppp-8a9babb739f2a9da045c749718bbe85aad5f0dd3.tar.gz accel-ppp-8a9babb739f2a9da045c749718bbe85aad5f0dd3.zip | |
writing code ...
| -rw-r--r-- | accel-pptpd/ppp.h | 15 | ||||
| -rw-r--r-- | accel-pptpd/ppp_fsm.h | 14 | ||||
| -rw-r--r-- | accel-pptpd/ppp_lcp.c | 136 | ||||
| -rw-r--r-- | doc/README | 15 | ||||
| -rw-r--r-- | doc/README.Reference | 15 | ||||
| -rw-r--r-- | doc/ms-chap.txt | 1139 | ||||
| -rw-r--r-- | doc/pptp-draft.txt | 3472 | ||||
| -rw-r--r-- | doc/rfc1661.txt | 2976 | ||||
| -rw-r--r-- | doc/rfc1662.txt | 1436 | ||||
| -rw-r--r-- | doc/rfc1701.txt | 451 | ||||
| -rw-r--r-- | doc/rfc1702.txt | 227 | ||||
| -rw-r--r-- | doc/rfc1990.txt | 1347 | ||||
| -rw-r--r-- | doc/rfc791.txt | 2887 | ||||
| -rw-r--r-- | doc/rfc793.txt | 5247 |
14 files changed, 19345 insertions, 32 deletions
diff --git a/accel-pptpd/ppp.h b/accel-pptpd/ppp.h index e640229f..8e8558bb 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 f07735d1..c4430c4d 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 8f9c88b9..8b4e4777 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 00000000..a76719b1 --- /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 00000000..a76719b1 --- /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 00000000..f009400b --- /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 00000000..f58701b3 --- /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 00000000..02112bd2 --- /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 00000000..5a5b214c --- /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 00000000..60a0e9b9 --- /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 00000000..50b57ae3 --- /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 00000000..a4f7ffef --- /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 00000000..5952d0b4 --- /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 00000000..603a78c8 --- /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] + |