Rfc 2637 pdf

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. Recur Bits Recursion control.

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 Must be set to zero 0. Protocol Type Set to hex B [ 8 ]. Key Use of the Key field is up to the implementation. Sequence Number Contains the sequence number of the payload. Present if S bit Bit 3 is one 1. 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. 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. Initial Window Size Although each side has indicated the maximum size of its receive window, it is recommended that a conservative approach be taken when beginning to transmit data.

The initial window size on the transmitter is set to half the maximum size the receiver requested, with a minimum size of one packet.

The transmitter stops sending packets when the number of packets awaiting acknowledgment is equal to the current window size. As the receiver successfully digests each window, the window size on the transmitter is bumped up by one packet until the maximum is reached. This method prevents a system from flooding an already congested network because no history has been established. 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. 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.

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. 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. Out-of-sequence Packets Occasionally packets lose their sequencing across a complicated internetwork.

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. To do so could cause problems, as proper PPP protocol operation is premised upon receiving packets in sequence.

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. A robust implementation will silently discard duplicate GRE packets, should it receive any. 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.

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.

For the PNS, this number should be small. For a PAC making modem connections, this number could be significant. Sample is the actual amount of time incurred receiving an acknowledgment for a packet. The Sample is measured, not calculated.

Round-Trip Time RTT is the estimated round-trip time for an Acknowledgment to be received for a given transmitted packet. When the network link is a local network, this delay will be minimal if not zero. When the network link is the Internet, this delay could be substantial and vary widely. RTT is adaptive: it will adjust to include the PPD and whatever shifting network delays contribute to the time between a packet being transmitted and receiving its acknowledgment.

After a time-out, the sliding window is partially closed and the ATO is backed off. 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. 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. 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 implementation and is explained in [ 11 ]. DIFF is calculated on each iteration. DEV is the estimated mean deviation. This approximates the standard deviation. DEV is calculated on each iteration and stored for use in the next iteration. Initially, it is set to 0. RTT is the estimated round-trip time of an average packet. RTT is ycalculated on each iteration and stored for use in the next iteration. Initially, it is set to PPD.

ATO is the adaptive time-out for the next transmitted packet. ATO is calculated on each iteration. Chi is the gain for the time-out and is typically set to 4. With the suggested gain constants, they should be scaled by 8 to eliminate all division. To simplify calculations, all gain values are kept to powers of two so that shift operations can be used in place of multiplication or division. When a time-out occurs, the time- out value should be adjusted rapidly upward.

Although the GRE packets are not retransmitted when a time-out occurs, the time-out should be adjusted up toward a maximum limit. To compensate for shifting internetwork time delays, a strategy must be employed to increase the time-out when it expires notice that in addition to increasing the time-out, we are also shrinking the size of the window as described in the next section.

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. Because the PPTP control channel messages are neither authenticated nor integrity protected, it might be possible for an attacker to hijack the underlying TCP connection. It is also possible to manufacture false control channel messages and alter genuine messages in transit without detection.

The GRE packets forming the tunnel itself are not cryptographically protected. Because the PPP negotiations are carried out over the tunnel, it may be possible for an attacker to eavesdrop on and modify those negotiations. References [ 1 ] Hanks, S. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works.

However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Informational [Page 57]. We will also define intermediate values b1, b2, etc. The above process is then reversed to yield the original value. After each AVP title follows a short description of the purpose of the AVP, a detail including a graphic of the format for the Attribute Value, and any additional information needed for proper use of the avp.

See Section 3. Rather than an indication as to whether the AVP itself should be ignored if not recognized, it is an indication as to whether the control message itself should be ignored. If the M-bit is not set, then the implementation may ignore an unknown message type. The Length of this AVP is 8. The optional Error Code is a 2 octet unsigned integer. An optional Error Message can follow the Error Code field. Presence of the Error Code and Townsley, et al. The Error Message contains an arbitrary string providing further human readable text associated with the condition.

If an L2TP reply indicates in Townsley, et al. The currently defined General Error codes and their meanings are: 0 - No general error 1 - No control connection exists yet for this LAC-LNS pair 2 - Length is wrong 3 - One of the field values was out of range or reserved field was non-zero 4 - Insufficient resources to handle this operation now 5 - The Session ID is invalid in this context 6 - A generic vendor-specific error occurred in the LAC 7 - Try another.

Rev field is a 1 octet unsigned integer containing 0. This pertains to L2TP protocol version 1, revision 0. Note this is not the same version number that is included in the header of each message. If bit A is set, asynchronous framing is supported. If bit S is set, synchronous framing is supported. Attempts to do so will result in the call being rejected.

This AVP may be hidden the H-bit may be 0 or 1. The Length before hiding is If bit A is set, analog access is supported. If bit D is set, digital access is supported. Presence of this message is not a guarantee that a given outgoing call will be placed by the sender if requested, just that the physical capability exists.

The lower value "wins", and the "loser" MUST silently discard its tunnel. In the case where a tie breaker is present on both sides, and the value is equal, both sides MUST discard their tunnels. If neither side issues a tie breaker, then two separate tunnels are opened. The Length of this AVP is For devices which do not have a firmware revision general purpose computers running L2TP software modules, for instance , the revision of the L2TP software module may be reported instead.

The Length before hiding is 8. The Length before hiding of this AVP is 8. If absent, the peer must assume a Window Size of 4 for its transmit window. The remote peer may send the specified number of control messages before it must wait for an acknowledgment.

The Length before hiding of this AVP is Before the Townsley, et al. The Call Serial Number is intended to be an easy reference for administrators on both ends of a tunnel to use when investigating call failure problems. Call Serial Numbers should be set to progressively increasing values, which are likely to be unique for a significant period of time across all interconnected LNSs and LACs.

If set, bit A indicates that the call refers to an analog channel. If set, bit D indicates that the call refers to a digital channel. Both may be set, indicating that the call was either indistinguishable, or can be placed on either type of channel.

Such a setting may indicate that the call was not received over a physical link e. Bit A indicates asynchronous framing. Bit S indicates synchronous framing. For an OCRQ, both may be set, indicating that either type of framing may be used. For example, if the LNS is individually connected to several private networks using unregistered addresses, this AVP may be included by the LAC to indicate that a given call should be associated with one of the private networks.

The Private Group ID is a string corresponding to a table in the LNS that defines the particular characteristics of the selected group. The Length of this AVP is 6. In this case, these AVPs may be included to indicate the Townsley, et al. If it is not present, then it is assumed that this peer cannot perform proxy authentication, requiring a restart of the authentication phase at the LNS if the client has already entered this phase with the LAC which may be determined by the Proxy LCP AVP if present.

Associated AVPs for each type of authentication follow. It contains the name specified in the client's authentication response. It may be desirable to employ AVP hiding for obscuring the cleartext name. The Length before hiding is 6 plus the length of the cleartext name. For 3, it is the Identifier value of the Authenticate-Request. The Response field contains the client's response to the challenge.

For Proxy authen types 2 and 5, this field contains the response value received by the LAC. For types 1 or 3, it contains the clear text password received from the client by the LAC. In the case of cleartext passwords, AVP hiding is recommended.

The LAC should honor these fields unless it has specific configuration information to indicate that the requested mask must be modified to permit operation. Establishment of the control connection includes securing the identity of the peer, as well as identifying the peer's L2TP version, framing, and bearer capabilities, etc.

A three message exchange is utilized to setup the control connection. If the expected response and response received from a peer does not match, establishment of the tunnel MUST be disallowed. This is the same shared secret used for AVP hiding see Section 4. See Section 4. For the cases where a Session ID has not yet been assigned by the peer i. These are used to provide a reliable control message transport see Section 5. Each peer maintains separate sequence numbers for the control connection and each individual data session within a tunnel.

Unlike the L2TP control channel, the L2TP data channel does not use sequence numbers to retransmit lost data messages. The LNS controls enabling and disabling of sequence numbers by sending a data message with or without sequence numbers present at any time during the life of a session. Thus, if the LAC receives a data message without sequence numbers present, it MUST stop sending sequence numbers in future data messages.

If the LAC receives a data message with sequence numbers present, it MUST begin sending sequence numbers in future outgoing data messages. If the LNS enables sequencing after disabling it earlier in the session, the sequence number state picks up where it left off before. The LNS may initiate disabling of sequencing at any time during the session including the first data message sent. It is recommended that for connections where reordering or packet loss may occur, sequence numbers always be enabled during the initial negotiation stages of PPP and disabled only when and if the risk is considered acceptable.

For example, if the PPP session being tunneled is not utilizing any stateful compression or encryption protocols and is only carrying IP as determined by the PPP NCPs that are established , then the LNS might decide to disable sequencing as IP is tolerant to datagram loss and reordering. This is accomplished by injecting Hello control messages see Section 6. As for any other control message, if the Hello message is not reliably delivered then the tunnel is declared down and is reset.

The transport reset Townsley, et al. After the last session is cleared, the control connection MAY be torn down as well and typically is.

The recommended time for a full retransmission cycle is 31 seconds see section 5. Thus, it is not necessary to clear each session individually when tearing down the whole tunnel. The Nr and Ns fields of the control message header see section 3. The upper level functions of L2TP are not concerned with retransmission or ordering of control messages.

The reliable control message is a sliding window transport that provides control message retransmission and congestion control. Each peer maintains separate sequence number state for the control connection within a tunnel. The message sequence number, Ns, begins at 0. Each subsequent message is sent with the next increment of the sequence number.

The sequence number is thus a free running counter represented modulo The sequence number in the header of a received message is considered less than or equal to the last received number if its value lies in the range of the last received number and the preceding values, inclusive. For example, if the last received sequence number was 15, then messages with sequence numbers 0 through 15, as well as through , would be considered less than or equal. Such a message would be considered a duplicate of a message already received and ignored from processing.

However, in order to ensure that all messages are acknowledged properly particularly in the case of a lost ZLB ACK message , receipt of duplicate messages MUST be acknowledged by the reliable transport. All control messages take up one slot in the control message sequence number space, except the ZLB acknowledgement. Thus, Ns is not incremented after a ZLB message is sent.

The last received message number, Nr, is used to acknowledge messages received by an L2TP peer. It contains the sequence number of the message the peer expects to receive next e. While the Nr in a received ZLB is used to flush messages from the local retransmit queue see below , Nr of the next message sent is not be updated by the Ns of the ZLB.

The reliable transport at a receiving peer is responsible for making sure that control messages are delivered in order and without duplication to the upper level.

Messages arriving out of order may be queued for in-order delivery when the missing messages are received, or they may be discarded requiring a retransmission by the peer. The message at the front of the queue is sent with a given Ns value, and is held until a control message arrives from the peer in which the Nr field indicates receipt of this message.

After a period of time a recommended default is 1 second passes without acknowledgement, the message is retransmitted. The retransmitted message contains the same Ns value, but the Nr value MUST be updated with the sequence number of the next expected message. Each subsequent retransmission of a message MUST employ an exponential backoff interval. Thus, if the first retransmission occurred after 1 second, the next retransmission should occur after 2 seconds has elapsed, then 4 seconds, etc.

An implementation MAY place a cap upon the maximum interval between retransmissions. This cap MUST be no less than 8 seconds per retransmission. When a tunnel is being shut down for reasons other than loss of connectivity, the state and reliable delivery mechanisms MUST be maintained and operated for the full retransmission interval after the final message exchange has occurred. A sliding window mechanism is used for control message transmission. B is now allowed to have up to N outstanding control messages.

Once N have been sent, it must wait for an acknowledgment that advances the window before sending new control messages. An implementation may support a receive window of only 1 i. When retransmitting control messages, a slow start and congestion avoidance window adjustment procedure SHOULD be utilized.

The recommended procedure for this is described in Appendix A. An L2TP implementation is expected to be able to keep up with incoming control messages, possibly responding to some with errors reflecting an inability to honor the requested action. Appendix B contains examples of control message transmission, acknowledgement, and retransmission.

All data is sent in network order high order octets first. Any "reserved" or "empty" fields MUST be sent as 0 values to allow for protocol extensibility. SCCCN completes the tunnel establishment process. Some, such as the provision of secure access to corporate intranets via the Internet, are characterized by voluntary tunneling: the tunnel is created at the request of the user for a specific purpose.

Other applications involve compulsory tunneling: the tunnel is created without any action from the user and without allowing the user any choice in the matter, as a service of the Internet service provider ISP. Typically, ISPs providing a service want to collect data regarding that service for billing, network planning, etc.

Zorn, et al. In addition, several new values for the Acct-Status-Type attribute are proposed. Specific recommendations for, and examples of, the application of this attribute for the L2TP protocol can be found in RFC Implementation Notes Compulsory tunneling may be part of a package of services provided by one entity to another.

For example, a corporation might contract with an ISP to provide remote intranet access to its employees via compulsory tunneling. In this case, the integration of RADIUS and tunnel protocols allows the ISP and the corporation to synchronize their accounting activities so that each side receives a record of the user's resource consumption. This provides the corporation with the means to audit ISP bills. In addition, no method for determining the Call-Serial-Number is specified, which leaves open the possibility of wrapping after a reboot.

Note that a bit Call-Serial-Number is not sufficient to distinguish a given call from all other calls over an extended time period.