L2TP Tunnel keepalive control channel
draft-nautiyal-l2tpext-tunnel-ka-control-channel-00

Document Type Active Internet-Draft (individual)
Author Yogesh Nautiyal 
Last updated 2021-06-23
Stream (None)
Intended RFC status (None)
Formats pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
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