Network Working Group Y. Nautiyal Internet-Draft Juniper Networks Intended status: Standard Track June 23 2021 Expires: November 2021 L2TP Tunnel keepalive control channel draft-nautiyal-l2tpext-tunnel-ka-control-channel-00.txt Abstract This memo defines a dedicated control channel for L2TP tunnel keepalives for use in deployment which has control plane and user plane seperation. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." Copyright Notice Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Introduction L2TP tunnel uses keepalive mechanism where it sends Hello control message and waits for its acknowledgement. Each control message in L2TP carries sequence numbers. More formally there are Ns and Nr sequence numbers in L2TP header for control messages. Ns" stands for next-send sequence number of the local tunnel endpoint, and "Nr" stands for next-receive sequence number from the peer tunnel endpoint. Since Hello messages also carries sequence numbers so they needs to be handled by the same control plane. For the deployment which seperate control plane and user plane, a node managing multiple user planes may become a choking point for handling keepalives of different user planes. A dedicated control channel for keepalives may help to off-load their handling to each individual user plane. 2. Dedicated Hello control channel negotiation The two L2TP endpoints of the tunnel negotiate for the usage of dedicated Hello control channel if supported. If a implementation support dedicated Hello control channel it should be able to support it in both modes i.e, with sequencing and sequencing disabled. 2.1 Dedicated Hello control channel AVP This is the new L2TP control message AVP assigned by IANA used for this negotiation. The Hello control channel AVP has Mandatory bit 'M' and Hidden bit 'H'set to 0 in L2TP header. The AVP value is one byte long and has value that can be 0, 1, or 2. AVP value of 0 means Hello control channel is not supported. AVP value of 1 means Hello control channel is supported without sequencing enabled. AVP value of 2 means Hello control control channel is supported with sequence numbers. The tunnel initiator include Hello control channel AVP in SCCRQ message if it is supported. The other side on receipt of SCCRQ message responds with SCCRP message and include Hello control channel AVP if it is supported. The tunnel initiator will then know if the remote side also supports the dedicated hello control channel or not. 3 Dedicated Hello control channel message 3.1 Dedicated Hello control channel sequencing enabled Hello control channel uses its own sequencing number management. A new L2TP message type is used to identify this Hello message from the existing Hello message. The receiving node on seeing this Hello message will be knowing if it needs to handle it in separate control channel or not. The Ns/Nr if to be used on dedicated hello control channel should be generated and handled as per existing mechanism for L2TP per RFC 2580. But these sequence numbers will be solely used for the keepalives management only. A node will not use the sequence numbers from the hello control channel to acknowledge non-hello control messages. Neither should a node use the sequence numbers from the hello control channel to transmit a non-hello message. 3.2 Dedicated Hello control channel sequencing disabled An implementation can also configure the Hello control channel to not use the sequencing for the Hello messages at all. This means that the dedicated control channel Hello message will not contain any Ns/Nr values in the L2TP header. For this a L2TP node will informs its peer by setting the appropriate value of the AVP for dedicated hello control channel in SCCRQ/SCCRP message. For the incoming Hello message a L2TP node will simply acknowledge it by sending ZLB but devoid of any Ns/Nr values in it. 4. Backward Compatibility Since the mechanism in this document uses new control message type, it is made to be compatible to existing implementation also. At the time of L2TP negotiation both sides negotiates for use of dedicated hello control channel. If the negotiations is successful then dedicated hello control channel is used, otherwise the existing mechanism stays. 3. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 8. Security Considerations. Hello control channel may be operating on a different machine possibly but under superior control of the machine handling control plane. A spoofing attempt by a machine to hijack a hello control channel should be prevented. 9. IANA Considerations L2TP Hello message on dedicated control channel: This document introduces new message type for Hello on dedicated channel. The new message type is IANA-assigned for L2TP message type AVP. Descriptor Value ---------- ----------------------- Hello on dedicated control channel 30 L2TP control message type AVP for the hello on dedicated control channel: Descriptor Value ---------- ------------------------ Hello dedicated control channel 30 control message type 11. References 11.1. Normative References [RFC 2661] W. Townsley, A. Valencia, A. Rubens, G. Pall, G.Zorn, B. Palter, "Layer 2 Tunnel Protocol (L2TP)", August 1999.atements for SMIv2", STD 58, RFC 2580, April 1999. 11.2. Informative References [RFC2223] Postel, J. and J.K. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC2629] Rose, M.T., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB Documents", BCP 111, RFC 4181, September 2005. 11.3. URL References [idguidelines] IETF Internet Drafts editor, "http://www.ietf.org/ietf/1id-guidelines.txt", . [idnits] IETF Internet Drafts editor, "http://www.ietf.org/ID-Checklist.html", . [xml2rfc] XML2RFC tools and documentation, "http://xml.resource.org", . [ops] the IETF OPS Area, "http://www.ops.ietf.org", . [ietf] IETF Tools Team, "http://tools.ietf.org", . Author's Address Yogesh Nautiyal Juniper Networks 10 Technology Park Drive Westford, MA 01886 Phone: EMail: yogeshn@juniper.net