RFC 4951
Fail Over Extensions for Layer 2 Tunneling Protocol (L2TP) "failover"
Fail Over Extensions for Layer 2 Tunneling Protocol (L2TP) "failover" 💖
Bestie, here's the title block tea 🫖: this is RFC 4951 🎀, written by V. Jain, Ed. from Riverstone Networks 🏢. It's a Standards Track doc, dated August 2007 📅. The header doesn't list any "Obsoletes" or "Updates" lines, so it doesn't say it replaces or changes any other RFC 🦋.
Status of This Memo ✨
okay so this one is an Internet standards track protocol for the Internet community 🌐, and the authors are literally asking everyone to discuss it and suggest improvements 💅. If you want the official standardization state and status of this protocol, you check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited, so share it freely 🫶.
Copyright Notice 🔐
the legal bit: Copyright (C) The IETF Trust (2007). 📜
Abstract 🌸
L2TP is a connection-oriented protocol 🔗, which means the active endpoints share state with each other 👯. Some of that shared state is super important for things to work, but it's also kinda volatile 🫠. The big example is packet sequence numbers used on the L2TP Control Connection 🔢.
Here's the plot 🎬: when one side of a control connection fails, a new control connection gets created 🆕. It then gets linked to the old one by swapping info about the old connection 🤝. This is NOT meant to replace an active failover with mirrored connection states, ngl 🙅♀️. It's more like a helper for the parameters that are really hard to have ready right away 🧚.
The extensions in this document are built to help recover state 🩹, add extra resiliency to an L2TP network 💪, and make a remote system's layer 2 connectivity better 🌈. Main character energy ✨👑.
Table of Contents 📋
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. Abbreviations ..............................................5
1.3. Specification of Requirements ..............................5
2. Overview ........................................................5
3. Failover Protocol ...............................................7
3.1. Failover Capability Negotiation ............................7
3.2. Failover Recovery Procedure ................................7
3.2.1. Recovery Tunnel Establishment .......................8
3.2.2. Control Channel Reset ..............................10
3.2.3. Data Channel Reset .................................10
3.3. Session State Synchronization .............................11
4. New Control Messages ...........................................12
4.1. Failover Session Query ....................................13
4.2. Failover Session Response .................................13
5. New Attribute Value Pairs ......................................14
5.1. Failover Capability AVP ...................................14
5.2. Tunnel Recovery AVP .......................................15
5.3. Suggested Control Sequence AVP ............................16
5.4. Failover Session State AVP ................................17
6. Configuration Parameters .......................................18
7. IANA Considerations ............................................19
8. Security Considerations ........................................19
9. Acknowledgements ...............................................19
10. Contributors ..................................................20
11. References ....................................................20
11.1. Normative References .....................................20
11.2. Informative References ...................................20
Appendix A ........................................................21
Appendix B ........................................................23
Appendix C ........................................................241. Introduction ✨
okay bestie, the whole goal here is to make an L2TP endpoint more resilient 💪 by adding extensions to RFC 2661 [L2TPv2] and RFC 3931 [L2TPv3]. The aim is to shrink how long the L2TP layer takes to recover after a failover ⏱️, without wrecking its performance 🏎️. It's also assumed the endpoint's overall architecture helps with the resiliency effort 🧱.
To run properly after a failover 🔄, the info tied to the control connection and the sessions between the peers has to be correct and consistent 💯. That covers both configured info and dynamic info 🗂️. The configured info is assumed to still be correct and consistent after a failover, because otherwise the tunnels and sessions wouldn't have been set up in the first place 🙃.
The dynamic info (also called stateful info) changes as the tunnel's control and data packets get processed 🌀. Right now the only dynamic info that's essential to the tunnel working is its sequence numbers 🔢. For the tunnel control channel, messed-up sequence numbers can end the whole tunnel 💀. For tunnel sessions, messed-up sequence numbers (when they're used) can cause big data loss 📉, which feels like "service loss" to the end user 😭.
So a good resilient setup that tries to minimize "service loss" after a failover has to handle the tunnel's essential stateful info, meaning its sequence numbers 🧠. Right now there are two options 🪄. Option one is to keep the backup endpoint completely synced with the active endpoint for the control and data session sequence numbers 🔁. Option two is to rebuild all the tunnels and their sessions after a failover 🏗️. The downside of option one is that it adds a lot of performance and complexity to the endpoint's architecture, especially as tunnel and session aggregation grows 😵💫. The downside of option two is that the "service loss" time goes up, especially as the architecture scales 📈.
To fix those downsides 🛠️, this document brings in a mechanism that gets the dynamic stateful info of a tunnel back to a correct and consistent state after a failure 🎉. It defines how tunnels and sessions that were in an established state before the failure get recovered 🦸♀️.
1.1. Terminology 📖
Here's the vocab you need, periodt 💅:
- Endpoint: an L2TP control connection endpoint, i.e., either LAC or LNS (also known as LCCE in [L2TPv3]) 🔌.
- Active Endpoint: an endpoint that's currently providing service 🟢.
- Backup Endpoint: a redundant endpoint on standby for the active endpoint, with its database of active tunnels and sessions in sync with that active endpoint 🪞.
- Failed Endpoint: the endpoint that was the active endpoint when the failure happened 💔.
- Recovery Endpoint: the endpoint that starts the failover protocol to recover from the failure of an active endpoint 🚑.
- Remote Endpoint: the endpoint that peers with the active endpoint before the failure and with the recovery endpoint after the failure 🤝.
- Failover: the action of a backup endpoint taking over the service of an active endpoint 🔀. This could happen because of administrative action or because the active endpoint failed 🧑💼.
- Old Tunnel: a control connection that existed before the failure and gets recovered during failover 🕰️.
- Recovery Tunnel: a brand new control connection set up only to recover an old tunnel 🆕.
- Recovered Tunnel: once an old tunnel's control connection and sessions are restored using the mechanism in this document, it's called a Recovered Tunnel 🎊.
- Control Channel Failure: failure of the component responsible for establishing and maintaining tunnels and sessions at an endpoint 🫣.
- Data Channel Failure: failure of the component responsible for forwarding the L2TP encapsulated data 📦.
1.2. Abbreviations 🔤
Quick cheat sheet, bestie 🧚:
LAC L2TP Access Concentrator
LNS L2TP Network Server
LCCE L2TP Control Connection Endpoint
AVP Attribute Value Pair
SCCRQ Start-Control-Connection-Request
SCCRP Start-Control-Connection-Reply
ZLB Zero Length Body Message1.3. Specification of Requirements 🎀
this part is super important, so pay attention 👀. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 📏. Those words are the official requirement language 🗣️, so they carry real weight 🔥.
- Overview ✨
okay so bestie, this section is the big picture 🧚 It's giving "here's the whole cast of characters and how they relate" 💅
The following diagram depicts the redundancy architecture and pertaining entities used to describe the failover protocol:
+--------------+
| L2TP active |
+----------+ ----| endpoint (A) |
| L2TP | / +--------------+
| endpoint |----------------------/
| (R) | \ +--------------+
+----------+ \ | L2TP backup |
----| endpoint (B) |
+--------------+ngl the diagram is literally the whole plot 🦋 Active and backup endpoints may reside on the same device, however, they are not required to be that way. On other hand, some devices may not have a standby module altogether, in which case the failed endpoint, after reset, can become the recovery endpoint to recover from its prior failure. 🌸
So, in the above diagram, upon A's (active endpoint's) failure:
- Endpoint A would be called the failed endpoint. 💀
- If B is present, then it would become the recovery endpoint and also an active endpoint. 👑
- If B is not present, then A could become the recovery endpoint after it restarts, provided it saved the information about active tunnels/sessions in some persistent storage. 🫶
- R does not initiate the failover protocol; rather it waits for a failure indication from recovery endpoint. 🙈
This document assumes that the actual detection of a failure in the backup endpoint is done in an implementation-specific way. It also assumes that failure detection by the backup endpoint is faster than the L2TP control channel timeout between the active and remote endpoints. Typically, active and backup endpoints reside on the same physical device, allowing fast and reliable failure detection without the need to communicate between these endpoints over the network. ✨
Similarly, an active endpoint that acts also as a backup endpoint can easily start the recovery once it has rebooted. However, when the active and backup endpoints reside in separate devices, there is a need for communication between them in order to detect failures. As a solution for such situations, additional failure detection protocols, e.g., [BFD-MULTIHOP], may be needed. 🔥
A device could have three kinds of failures:
- i) Control Channel Failure 🎀
- ii) Data Channel Failure 🎀
- iii) Control and Data Channel Failure 🎀
The protocol described in this document specifies the recovery in conditions i) and iii). It is perceived that not much (stateful information) could be recovered via a control protocol exchange in case of ii). 🌈
The failover protocol consists of three phases:
- Failover Capability Negotiation: An active endpoint and a remote endpoint exchange failover capabilities and attributes to be used during the recovery process.
- Failover Recovery: A recovery endpoint establishes a new L2TP control connection (called recovery tunnel) for every old tunnel that it wishes to recover. The recovery tunnel serves three purposes:
- It identifies the old tunnel that is being recovered.
- It provides a means of authentication and a three-way handshake to ensure both ends agree on the failover for the specified old tunnel.
- It could exchange the Ns and Nr values to be used in the recovered tunnel.
Upon establishing the recovery tunnel, two endpoints reset the control and data channel(s) on the recovered tunnel using the procedures described in Section 3.2.2 and Section 3.2.3, respectively. The recovery tunnel could be torn down after that, and sessions that were established resume traffic. 💖
- Session State Synchronization: The session state synchronization process occurs on the recovered or the old tunnel and allows the two endpoints to agree on the state of the various sessions in the tunnel after failover. The inconsistency, which could arise due to the failure, is handled in the following manner: first, the two endpoints silently clear the sessions that were not in the established state. Then, they utilize Failover Session Query (FSQ) and Failover Session Response (FSR) on the recovered tunnel to obtain the state of sessions as known to the peer endpoint and clear the sessions accordingly. 🧚
3. Failover Protocol 💅
The protocol consists of three steps describing specifications during the life of a control connection - before and after failover. 🦋
3.1. Failover Capability Negotiation
The active and remote endpoints exchange the Failover Capability attribute-value pair (AVP) in Start-Control-Connection-Request (SCCRQ) and Start-Control-Connection-Reply (SCCRP) during control connection establishment as a part of the normal (before failover) operation. The Failover Capability AVP, defined in Section 5.1, allows an endpoint to specify if it is control and/or data channel failover capable and the time allowed for the recovery for the tunnel. 🫶
3.2. Failover Recovery Procedure
The Failover Recovery Procedure described in this section is performed only if there was a control channel failure. The selection of the tunnels to be recovered is implementation specific. 🌸
The Failover Recovery Procedure consists of following three steps, which are described in detail in the subsections below:
- Recovery tunnel establishment
- Control channel reset
- Data channel reset
3.2.1. Recovery Tunnel Establishment
The recovery endpoint establishes a new control connection, called recovery tunnel, for every old tunnel it wishes to recover. The purpose of the recovery tunnel is solely to recover the corresponding old tunnel. There is a one to one relationship between recovery tunnel and recovered/old tunnel 💜
Recovery tunnel establishment considerations:
- An LCCE MUST follow the procedures described in [L2TPv2] or [L2TPv3] to establish the recovery tunnel. 🎀
- The recovery tunnel MUST use the same L2TP version (and establishment procedures) that was used for the old tunnel. 🎀
- The SCCRQ for Recovery tunnel MUST include the Tunnel Recovery AVP, defined in Section 5.2, to identify the old tunnel that is being recovered. 🎀
- The recovery tunnel MUST NOT include the Failover Capability AVP in its SCCRQ or SCCRP messages. 🎀
- An endpoint SHOULD NOT send any message other than the following on the recovery tunnel: SCCRQ, SCCRP, SCCCN, StopCCN, HELLO, ZLB, and ACK ([L2TPv3] only). 🎀
- An endpoint MUST NOT use any old Tunnel ID for the recovery tunnel. The old tunnels MUST be valid until the recovery process concludes. 🎀
- An endpoint MUST use the Tie Breaker AVP (Section 4.4.3 [L2TPv2]) or Control Connection Tie Breaker AVP (Section 5.4.3 [L2TPv3]) in the setup of the recovery tunnel to ensure that only a single recovery tunnel (when both endpoints have simultaneous failover) is established to recover an old tunnel. The tunnel that wins the tie is used to decide the suggested Ns and Nr values on the recovered tunnel. Therefore, the endpoint that loses the tie, should reset the Ns and Nr values (Section 3.2.2) as if it were a remote endpoint. Appendix B illustrates the double failover scenario. 🌈
- Tie Breaker AVP processing: The scope of a tie breaker AVP's action for recovery and non recovery tunnels must be independent, and is defined as follows:
- When Tie Breaker AVP is used in a non recovery tunnel, the scope of the tie breaker AVP's action MUST only be within non recovery tunnels. Therefore, losing a tie against a non recovery tunnel MUST NOT result in termination of any recovery tunnel. 🦋
- When a Tie Breaker AVP is used in a recovery tunnel, the scope of tie breaker AVP's action is further restricted to the recovery tunnel(s) for a single tunnel to be recovered. Thus, an implementation MUST apply the tie breaker received in a recovery tunnel only to those tunnels that are a) recovery tunnels, and b) associated with the same tunnel to be recovered. It MUST NOT impact the operation of non-recovery tunnels and recovery tunnels associated with other old tunnels to be recovered. 🦋
Upon getting an SCCRQ with a Tunnel Recovery AVP, an endpoint validates the Recover Tunnel ID and the Recover Remote Tunnel ID and responds with an SCCRP. It MUST terminate the recovery tunnel if:
- The Recover Tunnel ID or the Recover Remote Tunnel ID is unknown.
- The active or remote endpoint (prior to failover) had not indicated that it was failover capable.
- The L2TP version of recovery tunnel is different from the version used in the old tunnel.
If the remote endpoint accepts the SCCRQ, it SHOULD include the Suggested Control Sequence AVP, defined in Section 5.3, in the SCCRP message. 💅
Authentication considerations:
- To authenticate a peer endpoint during recovery tunnel establishment, an endpoint MUST follow the procedure described in either [L2TPv2] Section 5.1.1 or [L2TPv3] Section 4.3. It MUST use the same secret that was used to authenticate the old tunnel.
- Not being able to authenticate could be a reason to terminate the recovery tunnel.
- For L2TPv3 tunnels, a recovery tunnel MUST use the Control Message authentication (i.e., exchange the nonce values), as described in [L2TPv3] Section 4.3, if the old tunnel was configured to do control message authentication. An L2TPv3 recovered tunnel MUST reset its nonce values (both endpoints) to the nonce values exchanged in the recovery tunnel. 🔐
For any reason, if the recovery endpoint could not establish the recovery tunnel, then it MUST silently clear the old tunnel and sessions within, concluding that the recovery process has failed. 💀
Any control packet received on the recovered tunnel before control channel reset (Section 3.2.2) MUST be silently discarded. 🙈
3.2.2. Control Channel Reset
Control channel reset allows new control messages to be sent and received over the recovered tunnel. ✨
Control channel reset procedure:
- An endpoint SHOULD flush the transmit/receive windows and reset the control channel sequence numbers (i.e., Ns and Nr values) on the recovered tunnel. The control channel on the recovery endpoint is reset upon getting a valid SCCRP on the recovery tunnel, whereas the control channel on the remote endpoint is reset upon getting a valid SCCCN on the recovery tunnel. If the recovery endpoint did not receive the Suggested Control Sequence (SCS) AVP in the SCCRP then it MUST reset the Ns and Nr values to zero. If the remote endpoint opted to not send the SCS AVP then it MUST reset the Ns and Nr values to zero. Either endpoint can tear down the recovery tunnel after the control channel reset procedure is complete. 🌸
- An endpoint MUST prevent the establishment of new sessions until it has cleared (or marked for clearance) the sessions that were not in an established state, i.e., until after Step I, Section 3.3 is complete. 🛑
3.2.3. Data Channel Reset ✨
okay so a data channel reset procedure only applies to sessions that use sequence numbers 🦋 For the L2TPv3 data channel, Nr means "expected sequence number" and Ns means "sequence number" in this doc, so keep those straight bestie 💖
Data channel reset procedure:
- The recovery endpoint sets the
Nsvalue to zero. 🌸 - The remote endpoint (the recovery endpoint's peer) keeps using the
Nsvalues it was already using. 🫶 - To reset
Nrvalues during failover, if an endpoint gets 'n' packets that are out of order but still in sequence, it MUST set theNrvalue based on theNsvalue of the incoming packets, as suggested in Appendix C of [L2TPv3]. The value of 'n' SHOULD be configurable. ✨ - If one of the endpoints doesn't have the capability to reset
Nr(shown by the 'D' bit in the Failover Capability AVP), then data channels using sequence numbers are considered non recoverable 💀 Those sessions SHOULD be torn down by the recovery endpoint by sending a Call-Disconnect-Notify (CDN). 🙈 - For a data-channel-only failure, two endpoints MAY use the session state query/response mechanism on the control channel to synchronize the state of sessions, as described in Section 3.3 below. 💜
3.3. Session State Synchronization 💅
okay this part is giving drama 😭 If a control channel failure happens while a session is being established or torn down, then it's possible for an endpoint to think a session is established while its peer thinks that same session doesn't exist. Two situations like this can happen when a failure hits an endpoint right after it sends:
- A CDN message that never made it to the peer.
- An ICCN message that never made it to the peer.
The following mechanism MUST be used to identify and clear the sessions that exist on an endpoint but not on its peer. 🔥
Step I: For a control channel failure, after the recovery tunnel is established, the sessions that were not in an established state MUST be silently cleared (i.e., without sending a CDN message) by each endpoint. 🧚
Step II: Both endpoints MAY identify the sessions that might have been in inconsistent states, maybe based on data channel inactivity. FSQ and FSR messages were introduced so that session state can be synchronized at any point during a session's life between two endpoints. These messages get used when an endpoint determines, or suspects in an implementation-specific way, that its session state could be inconsistent with its peer's. 👑
Step III: An endpoint sends a Failover Session Query (FSQ) message to query the state of sessions as known to its peer. An FSQ message contains one Failover Session State (FSS) AVP, defined in Section 5.4, for each session it wants to query. Multiple FSS AVPs could be included in one FSQ message. An FSQ message MUST include at least one FSS AVP. An endpoint MAY send another FSQ message before getting a response for its previous FSQs. 🌈
An inconsistency about a session's existence during failover could make an endpoint pick the same Session ID for a new session. In that situation, it would send an ICRQ for a session that's already established 😳 So, before all sessions are synchronized using the FSQ/FSR mechanism, if an endpoint receives an ICRQ for a session in an established state, then it MUST respond to that ICRQ with a CDN. The CDN message must set the Assigned/Local Session ID AVP ([L2TPv2] Section 4.4.4, [L2TPv3] Section 5.4.4) to its local Session ID, and clear the session it considered established. Using a least recently used Session ID for new sessions could help reduce this symptom during failover. 🍓
When an endpoint receives an FSQ message, it MUST ensure that for each FSS AVP in the FSQ message, it includes an FSS AVP in the Failover Session Response (FSR) message. An endpoint could respond to multiple FSQs using one FSR message, or it could respond to one FSQ with multiple FSRs. FSSs are not required to be responded to in the same order they were received. For each FSS AVP received in FSQ messages, an endpoint MUST validate the Remote Session ID and determine whether it is paired with the Session ID specified in the message. If an FSS AVP is not valid (i.e., the session doesn't exist or it's paired with a different remote Session ID), then the Session ID field in the FSS AVP in the FSR MUST be set to zero. When a session is discovered to be paired with a mismatching Session ID, the local session MUST not be cleared, but rather marked stale, to be queried later using an FSQ message. Appendix C presents an example dialogue between two endpoints with mismatching Session IDs. 🦋
When responding to an FSQ with an FSR message, the Remote Session ID in the FSS AVP of the FSR message is always set to the received value of the Session ID in the FSS AVP of the FSQ message. 💖
When an endpoint receives an FSR message, for each FSS AVP it MUST use the Remote Session ID field to identify the local session. It silently (without sending a CDN) clears the session if the Session ID in the AVP was zero. Otherwise, it MUST consider the session to be in an established state and recovered. ✨
4. New Control Messages 🎀
This document introduces two new messages that could be sent over an established/recovered control connection. 🫶
4.1. Failover Session Query 🌸
The Failover Session Query (FSQ) control message is used by an endpoint during the recovery process to query the state of various sessions. It triggers a response from the peer, which contains the requested state of those sessions. 🔥
This control message is encoded as follows:
Vendor ID = 0 (IETF)
Attribute Type = 21The following AVPs MUST be present in the FSQ control message:
Message TypeFailover Session State
The following AVPs MAY be present in the FSQ control message:
Random VectorMessage digest([L2TPv3] tunnels only)
Other AVPs MUST NOT be sent in this control message and SHOULD be ignored on receipt. 💀
The M-bit on the Message Type AVP for this control message MUST be set to 0. 🧚
4.2. Failover Session Response 🦋
The Failover Session Response (FSR) control message is used by an endpoint during the recovery process to respond with the local state of various sessions. It's sent as a response to an FSQ message. An endpoint MAY choose to respond to an FSQ message with multiple FSR messages. 👑
This control message is encoded as follows:
Vendor ID = 0 (IETF)
Attribute Type = 22The following AVPs MUST be present in the FSR control message:
Message TypeFailover Session State
The following AVPs MAY be present in the FSR control message:
Random VectorMessage digest([L2TPv3] tunnels only)
Other AVPs MUST NOT be sent in this control message and SHOULD be ignored on receipt. 💅
The M-bit on the Message Type AVP for this control message MUST be set to 0. 🌈
5. New Attribute Value Pairs 👑
The following sections contain a list of new L2TP AVPs defined in this document. 💜
5.1. Failover Capability AVP ⭐
The Failover Capability AVP, Attribute Type 76, indicates the capabilities of an endpoint required for the recovery process. The AVP format is defined as follows:
Failover Capability AVP
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type 76 | Reserved |D|C|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Recovery Time (in milliseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The AVP MAY be hidden (the H-bit set to 0 or 1). The AVP is not mandatory (the M-bit MUST be set to 0). 🙈
The C bit governs the failover capability for the control channel. When the C bit is set, it indicates that the endpoint can recover from a control channel failure using the procedure described in Section 3.2.2. 🔥
When the C bit is not set, it indicates that the endpoint cannot recover from a control channel failover. In this case, the D bit MUST be set. Note that a control channel failover in this case would be fatal for the tunnel and all associated data channels. 💀
The D bit governs the failover capability for data channels that use sequence numbers. Data channels that don't use sequence numbers don't need help to recover from a data channel failure. 🧚
When the D bit is set, it indicates that the endpoint is capable of resetting the Nr value of data channels using the procedure described in Section 3.2.3 Data Channel reset procedure. 🦋
When the D bit is not set, it indicates that the endpoint cannot recover data channels that use sequence numbers. In the case of a failure, those data channels would be lost. 😭
The Failover Capability AVP MUST NOT be sent with the C bit and D bit cleared. 🫶
The Recovery Time, applicable only when the C bit is set, is the time in milliseconds an endpoint asks its peer to wait before assuming the recovery process has failed. This timer starts when an endpoint's control channel timeout ([L2TPv2] Section 5.8, [L2TPv3] Section 4.2) is started, and is not stopped (before expiry) until an endpoint successfully authenticates its peer during recovery. A value of zero does not mean that failover won't occur; it means no additional time is requested from the peer. The timer is also stopped if a control channel message is acknowledged by the peer in the situation where there was no failover, but the loss of the control channel message was a temporary phenomenon. 🌸
This AVP MUST NOT be included in any control message other than SCCRQ and SCCRP messages. 🌈
5.2. Tunnel Recovery AVP ✨
okay bestie, the Tunnel Recovery AVP is Attribute Type 77 💖 It's how a sender says "hey, I want this tunnel back because something failed" 🔥 The AVP tells the other side which tunnel to recover, so it's kind of the main character of recovery 👑
Here's what it looks like for L2TPv3 tunnels:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type 77 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Recover Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Recover Remote Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+And here's the L2TPv2 version 🌸
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type 77 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Recover Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Recover Remote Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The AVP MUST not be hidden, so the H-bit is set to 0 🙅♀️ It's mandatory too, so the M-bit is set to 1 💅
The Recover Tunnel ID is the local Tunnel ID that an endpoint wants recovered 🦋 The Recover Remote Tunnel ID is the remote Tunnel ID that goes with the old tunnel 🧚
This AVP MUST NOT be included in any control message other than the SCCRQ message when establishing a Recovery Tunnel. Only the SCCRQ, bestie. Nothing else 🙈
5.3. Suggested Control Sequence AVP 🎀
The Suggested Control Sequence (SCS) AVP is Attribute Type 78, and it's all about the Ns and Nr values for the recovered tunnel 💜 It gets included in the SCCRP message of a recovery tunnel, sent by the remote endpoint ✨ Here's the 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type 78 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suggested Ns | Suggested Nr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+This AVP MAY be hidden, so the H-bit is set to 0 or 1 🌈 It is not mandatory, so the M-bit is set to 0 🍓
It's an optional AVP that suggests the Ns and Nr values for the recovery endpoint to use 🫶 If it's in an SCCRP message during recovery tunnel establishment, the recovery endpoint MUST set the Ns and Nr values of the recovered tunnel to the suggested values 👑 If it isn't sent in an SCCRP, or isn't in an incoming SCCRP at all, then the Ns and Nr values for the recovered tunnel are set to zero 🙈 Using this AVP helps avoid interference with old control packets on the recovered tunnel's control channel. Iconic behaviour, honestly ✨
This AVP MUST NOT be included in any control message other than the SCCRP message when establishing a Recovery Tunnel. Again, SCCRP only, no exceptions 💀
5.4. Failover Session State AVP 🦋
The Failover Session State (FSS) AVP is Attribute Type 79 💖 It's used to ask the peer about the state of a session, so sessions don't get stuck in an undefined state after failover 🧹 Here are the formats:
FSS AVP format for L2TPv3 sessions:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type 79 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+FSS AVP format for L2TPv2 sessions:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type 79 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Remote Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+This AVP MAY be hidden, so the H-bit is set to 0 or 1 🙌 The AVP is mandatory, so the M-bit is set to 1 💅
The Session ID is the local Session ID that the sender assigned, and the sender wants to know the state of that session on its peer 🔍 The Remote Session ID is the remote Session ID for that same session ✨
An FSS AVP MUST NOT be used in any message other than FSQ and FSR messages. FSQ and FSR only, periodt 💀
6. Configuration Parameters 🎀
An L2TP endpoint MAY expose the following configuration parameters for control connections 💜
- Control Channel Failover Capability: Failover Capability AVP (Section 5.1),
Cbit. - Data Channel Failover Capability: Failover Capability AVP (Section 5.1),
Dbit. - Recovery Time: Failover Capability AVP (Section 5.1).
The L2TP MIB defined in [L2TPv2-MIB] and [L2TPv3-MIB] has a bunch of objects for monitoring L2TP nodes, but honestly it's seldom used for configuration 🙃 The parameters above are expected to be configured through a Command Line Interface (CLI) or some other proprietary mechanism 🧚
Asynchronous notifications for failover and recovery events may be sent by L2TP nodes to network management applications. The protocol and format for those notifications are out of the scope of this document, so that's a different story 🌸
7. IANA Considerations 🌈
This document defines the following values assigned by IANA 💖
- Four Control Message Attribute Value Pairs (Section 10.1 [L2TPv3]):
Failover Capability : 76
Tunnel Recovery : 77
Suggested Control Sequence : 78
Failover Session State : 79- Two Message Type (Attribute Type 0) Values (Section 10.2 [L2TPv3]):
Failover Session Query : 21
Failover Session Response : 228. Security Considerations 🔥
Okay, this one is serious, so I'm going to be real with you 😭
A spoofed failover request (an SCCRQ with a Tunnel Recovery AVP) made on behalf of an endpoint might cause a control channel termination if the authentication measures mentioned in Section 3.2.1 are not used 💀
Even if those authentication measures (as described in Section 3.2.1) were used, it's still possible to learn the identity of an operational tunnel from an endpoint. An attacker can do this by sending spoofed failover requests that fail the authentication procedure 👀 The probability of a spoofed failover request succeeding is 1 in (2^16 - 1) for [L2TPv2] and 1 in (2^32 - 1) for [L2TPv3] 🙈 The discovered identity of an operational tunnel could then be misused to send control messages, which could hinder the control connection 😱 Typically, control messages outside the endpoint's receive window are discarded 🛡️ However, if the Suggested Control Sequence AVP (Section 5.3) is not used during the actual failover process, the sequence numbers might be reset to zero, which makes the receive window predictable 😬 To improve security in that situation, an endpoint may be configured with the possible set of recovery endpoints that could recover a tunnel, and it may use the Suggested Control Sequence AVP when recovering a tunnel 🫶
9. Acknowledgements 💜
Leo Huber gave suggestions that helped define the failover concept 🧚 Mark Townsley, Carlos Pignataro, and Ignacio Goyret reviewed the document and gave valuable suggestions 🌸
10. Contributors ✨
Paul Howard Juniper Networks
Vipin Jain Riverstone Networks
Sam Henderson Cisco Systems
Keyur Parikh Harris Corporations11. References 📚
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[L2TPv2] Townsley, W., Valencia, A., Rubens, A., Pall, G.,
Zorn, G., and B. Palter, "Layer Two Tunneling Protocol
"L2TP"", RFC 2661, August 1999.
[L2TPv3] Lau, J., Townsley, M., and I. Goyret, "Layer Two
Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931,
March 2005.11.2. Informative References
[L2TPv2-MIB] Caves, E., Calhoun, P., and R. Wheeler, "Layer Two
Tunneling Protocol "L2TP" Management Information
Base", RFC 3371, August 2002.
[L2TPv3-MIB] Nadeau, T. and K. Koushik, "Layer Two Tunneling
Protocol (version 3) Management Information Base",
Work in Progress, August 2006.
[BFD-MULTIHOP] Katz, D. and D. Ward, "BFD for Multihop Paths", Work
in Progress, March 2007.Appendix A ✨
okay bestie, this one is a full example walkthrough of the failover protocol for a single tunnel 🦋 The failover protocol doesn't stop an endpoint from recovering multiple tunnels in parallel, so it's giving multitasking 💅 It also lets an endpoint send multiple FSQs, each with multiple FSS AVPs, so recovery is quick 🔥
Failover Capability Negotiation (Section 3.1)
first up, the two endpoints set up the tunnel and both say they're failover capable 🌸
Endpoint Peer
(assigned tid = x, failover capable)
SCCRQ --------------------------------------> validate SCCRQ
(assigned tid = y, failover capable)
validate <-------------------------------------- send SCCRP
SCCRP, etc.
.... <after tunnel gets created, sessions are established> ....Recovery Tunnel Establishment (Section 3.2.1)
then this node fails 💀 The Recovery endpoint sets up the recovery tunnel (Section 3.2.1) and starts recovery for the old tunnel 'x' 🧚
< This Node fails >
The Recovery endpoint establishes the recovery tunnel (Section 3.2.1).
Initiate recovery tunnel establishment for the old tunnel 'x':
Recovery Endpoint Peer
(assigned tid = z, Recovery AVP)
SCCRQ -----------------------------------> Detects failover
(recover tid = x, recover remote tid = y) validate SCCRQ
(Suggested Control Sequence AVP, Suggested Ns/Nr = 3/100)
validate <----------------------------------- send SCCRP
SCCRP (recover tid = y, recover remote tid = x)
reset Ns = 3, Nr = 100
on the recovered tunnel
SCCCN -----------------------------------> validate and reset
Ns = 100, Nr = 3 on
the recovered tunnel
Terminate the recovery tunnel
tid = 'z'
StopCCN --------------------------------------> Cleanup 'w'Session State Synchronization (Section 3.3)
once the sessions are synced, both endpoints can send FSQs and clean up stale sessions (Section 3.3) 🫶 It's basically a little back-and-forth where everyone checks what's still alive and who's stale 👑
Session states are synchronized both endpoints may send FSQs and
cleanup stale sessions (Section 3.3)
(FSS AVP for sessions s1, s2, s3..)
send FSQ -------------------------------------> compute the state
of sessions in FSQ
(FSS AVP for sessions s1, s2, s3...)
deletes <-------------------------------------- send FSR
stale sessions, if any
(FSS AVP for sessions s7, s8, s9...)
compute <-------------------------------------- send FSQ
the sate of
sessions in FSQ
(FSS AVP for sessions s7, s8, s9...)
send FSR --------------------------------------> delete stale
sessions, if anyAppendix B 🎀
this one shows double failure recovery, which is when both endpoints are recovery endpoints at the same time 🙈 The big difference from the single failover scenario (Section 3.2.1) is that one of the recovery endpoints uses a tie breaker to adopt the recovery tunnel its peer set up as its own recovery tunnel 💜
Recovery endpoint Recovery endpoint
(assume old tid = A) (assume old tid = B)
Recovery AVP = (A, B)
SCCRQ -----------------------+
(with tie (recovery tunnel 'C') |
breaker |
AVP) |
Recovery AVP = (B, A) |
+- valid <--------------------------- Send SCCRQ
| SCCRQ (recovery tunnel 'D') | (with tie breaker AVP)
| This endpoint |
| loses tie; |
| Discards tunnel 'C' +--> Valid SCCRQ
| This endpoint wins tie;
| Discards SCCRQ
|
| (may include SCS AVP)
+->Send SCCRP -------------------------> Validate SCCRP
Reset 'B';
Set Ns, Nr values --+
|
|
|
Validate SCCN <---------------------- Send SCCN -------+
Reset 'A';
Set Ns, Nr valuesonce the dust settles, both endpoints swap FSQs and FSRs for the old tunnel (A, B) over the recovered tunnel 🌈
Appendix C 🍓
okay, this one is spicy 🌶️ A Session ID mismatch can happen even when nobody actually failed. The catch is that failover session recovery can make things worse and leave the two endpoints stuck with a permanent mismatch in Session IDs 😭 This dialogue shows how the behaviour from Section 3.3, Step III handles it gracefully 🦋
Recovery endpoint Remote endpoint
(assume a mismatch) (assume a mismatch)
Sid = A, Remote Sid = B Sid = B, Remote Sid = C
Sid = C, Remote Sid = D
FSS AVP (A, B)
send FSQ -------------------------> No (B, A) pair exist;
rather (B, C) exist.
If it clears B then peer doesn't
know if C is stale on other end.
Instead if it marks B stale
and queries the session state
via FSQ, C would be cleared on
the other end.
FSS AVP (0, A)
Clears A <-------------------------- send FSR
... some time later ...
FSS AVP (B, C)
No (C,B) <-------------------------- send FSQ
Mark C Stale
FSS AVP (0, B)
Send FSR --------------------------> Clears BAuthor Information 🌸
here are the authors, the real MVPs who wrote this thing 👑
Vipin Jain
Riverstone Networks
5200 Great America Parkway
Santa Clara, CA 95054
EMail: vipinietf@yahoo.com
Paul W. Howard
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
EMail: phoward@juniper.net
Sam Henderson
Cisco Systems
7025 Kit Creek Rd.
PO Box 14987
Research Triangle Park, NC 27709
EMail: samh@cisco.com
Keyur Parikh
Harris Corporation
4393 Digitalway
Mason, OH 45040
EMail: kparikh@harris.comFull Copyright Statement ⭐
the legal bit, but make it cute 🎀 The IETF Trust holds the copyright on this document, which is Copyright (C) The IETF Trust (2007). The document is subject to the rights, licenses and restrictions in BCP 78, and apart from what BCP 78 sets out, the authors keep all their rights 🫶
The document and everything in it are provided "AS IS". The contributor, the organization they represent or are sponsored by (if any), the Internet Society, the IETF Trust and the Internet Engineering Task Force all disclaim every warranty, express or implied 💀 That includes any warranty that using the information won't infringe any rights, and any implied warranties of merchantability or fitness for a particular purpose.
Intellectual Property 🧚
the IETF doesn't take a side on whether any IPR or other rights someone claims about the technology in this document are valid, or how far they reach, and it doesn't say that it checked for any of them either 💅 Info about how RFC documents handle rights is in BCP 78 and BCP 79.
Copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses that will be available, and the outcome of any attempt to get a general license or permission for implementers or users are all findable in the IETF online IPR repository at http://www.ietf.org/ipr 🔥
The IETF also invites anyone to flag any copyrights, patents, patent applications or other proprietary rights that might cover technology needed to implement this standard. Send that to the IETF at ietf-ipr@ietf.org 🫶
Acknowledgement 🌈
the RFC Editor function is currently funded by the Internet Society 💜
📦 where this page comes from
- ietf: rfc4951 2007-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms